Skip to main content

Last Call Review of draft-herzog-static-ecdh-
review-herzog-static-ecdh-secdir-lc-weis-2011-03-03-00

Request Review of draft-herzog-static-ecdh
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-03-02
Requested 2011-02-01
Authors Jonathan Herzog , Roger Khazan
Draft last updated 2011-03-03
Completed reviews Secdir Last Call review of -?? by Brian Weis
Assignment Reviewer Brian Weis
State Completed
Review review-herzog-static-ecdh-secdir-lc-weis-2011-03-03
Completed 2011-03-03
review-herzog-static-ecdh-secdir-lc-weis-2011-03-03-00
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.

Brian