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 | |
I-D last updated | 2011-03-03 | |
Completed reviews |
Secdir Last Call review of -??
by Brian Weis
|
|
Assignment | Reviewer | Brian Weis |
State | Completed | |
Request | Last Call review on draft-herzog-static-ecdh by Security Area Directorate Assigned | |
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