Subject: Gen-ART review of draft-groves-sakke-00

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 4 Jan 2011 16:55:29 -0500

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-groves-sakke-00
Reviewer: Richard Barnes
Review Date: 04 Jan 2010
IETF LC End Date: 18 Jan 2010
IESG Telechat date: (if known)

Summary: It's not clear to me why this draft is necessary, given that there is already a published specification for the algorithm.  Putting that aside, the draft is not ready for publication.  

Major issues:

-- When I read this document, it's not clear to me what I would need to do to integrate this into a protocol.  In particular, it would be helpful to have a list of parameters according to:
(a) Which ones are constant for the whole algorithm
(b) Which ones are expected to be set out of band for a given implementation
(c) Which ones must be negotiated in the protocol
For example, the algorithm makes use of a hash function and an elliptic curve, but it's not clear how the communicating parties agree on what hash function or curves to use.

-- From a security perspective, the choice of a single static curve makes me uncomfortable.  This is not typical of other EC-based algorithms.  For example, RFC 4754, RFC 5091, and ECDSA (ANSI X9.62) all allow choices of curves, even if that choice is restricted to an enumerated set or a class.

-- If this document is extending RFC 5091, then it should formally extend it (as in, with a line at the top), and explain in more detail its relation to RFC 5091.

Minor issues:

-- The notation lg(x) for logarithms is not defined.  Suggest adding to the Notation section.

-- The normative references [MIKEY-SAKKE], [P1363], [P1363a] should be made informative.

-- The informative references [S-K], [SK-KEM] should be made normative

-- I have not checked whether the algorithm in this draft is the same as that described in references [S-K] [SK-KEM]

Nits/editorial comments:

-- Section 2.2 seems to have additional spaces at the beginning of each line.