[secdir] secdir review of draft-groves-eccsi-00.txt

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 19 January 2011 16:56 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD42428B56A; Wed, 19 Jan 2011 08:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.529
X-Spam-Level:
X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6vr70qb1RXf; Wed, 19 Jan 2011 08:56:19 -0800 (PST)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 310CD3A7178; Wed, 19 Jan 2011 08:56:19 -0800 (PST)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p0JGwvEV005422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 11:58:57 -0500 (EST)
Date: Wed, 19 Jan 2011 11:58:57 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: ietf@ietf.org, secdir@ietf.org, draft-groves-eccsi.all@tools.ietf.org
Message-ID: <1AF6DD3921E5919222492B24@minbar.fac.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
Subject: [secdir] secdir review of draft-groves-eccsi-00.txt
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: Wed, 19 Jan 2011 16:56: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.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines an identity-based encryption algorithm, using
elliptic-curve crypto, based in part on the design of ECDSA.  In the
system described, each participant has a well-known identifier and a
public/private key pair generated by a central keying authority, which
itself has a well-known public key.  Each participant's public key is
a function of that participant's identifer, the keying authority's
well-known public key, and a long-term "validation token" which is
initially provided the keying authority, and then transmitted by that
participant along with each of its signatures.

This system shares the usual security considerations of any public
key cryptosystem, of ECC in general, and of ECDSA in particular; the
security considerations section seems to do a reasonable job of calling
these out.  Recommendations are made for selecting an appropriate
group size based on the desired symmetric-equivalent strength, but no
information is given as to the  derivation of this advice.  I suggest
a reference to RFC3766, or perhaps some more recent document which
pays particular attention to ECC algorithms.

Naturally, the security of the system depends on secure delivery of
the agreed-upon group parameters, the keying authority's public key,
and the generated keying material to each participant.  This document
calls out the need for suitable protection, but considers protocols
or mechanisms for delivering this data to be out of scope.

No explicit mechanism is provided for revocation or expiration of
keys.  However, identifiers are free-form, and could easily be
extended to include timestamps, as discussed in the security
considerations section.  This is one of the most serious concerns
I have with any identity-based crypto scheme, and I'm glad to see
it called out and addressed.


This document is unusual for the IETF, in that it defines a new
cryptographic algorithm, which we normally don't do.  While there
is no particular reason not to publish it here, I would be wary
of using this algorithm in any IETF protocol until it has seen
extensive review by the cryptographic community.  It looks to me
like it should work, but I am not a cryptographer and may well
have missed an obvious flaw.