Dear colleagues: Please find below my (modest) comments on draft-herzog-static-ecdh-05 (an update of the document that occurred since the moment of issuing the LC). Best regards, Rene == I. Editorial comments: (E-a) p. 1, Disclaimer, l. 3: "conclusions and" should read "conclusions, and". (E-b) p. 11, Clause 7, l. -2: "Consder" should read "Consider". (E-c) p. 12, Clause 7, last para before two bullet points, l. 3: "reciever" should read "receiver". (E-d) p. 13, Clause 10.2, l. -3: The paper by Menezes and Ustaoglu has appeared in International Journal of Applied Cryptography, Vol. 2, No. 2, pp. 154-158, 2010. (E-e) p. 4, l. -5: The motivation for specifying ECDH seems to be not so much that ECMQV is around (but having problems, as you stated), but that static-static-ECDH is *not* around. Thus, specifying static-static-ECDH adds more options to the solution space. II. Technical comments: (T-f) p. 5, Clause 1, forelast bullet: The term "data integrity" is more aptly called "data authenticity" (and would also align well with AuthenticatedData CMS structure called out at the beginning of the same sentence). NOTE - I am aware of the "attack in Clause 7, but this attack seems to be more a flaw in the original CMS scheme, since effective irrespective of the key agreement method (i.e., not just static- static-ECDH): A --> B: E_K(k) || Secured_k(m) allows any entity C who obtains the same key k to replace Secured_k(m) by another valid string. This suggests that (1) one should call this out in the text; (2) one should fix the original problem with CMS (e.g., tieing k to K, the originator, or recipient via, e.g., a one-way function. (T-g) p. 6, Clause 2.2, l. -5: At first, it is suggested that the sending agent obtains the recipient's public key somehow (e.g., from its certificate), thus suggesting that certificates are not the only option by which the public key may be obtained. However, later on it is stated that "it confirms that both certificates [...]", thus suggesting that each of the parties involved in this message flow have public keys that are certified and that only those can be used. This is confusing. (T-h) p. 6, Clause 2.2, l. -6 ff: Given the lack of shall/should/may language, it is unclear whether one stipulates that one checks that public keys in the certificate are on a specific curve (i.e., one does public key validation) or something more relaxed (such as checking that the claimed elliptic curve domain parameters are the same, without checking the public keys themselves. The para would benefit from some firmed-up language here. This should also clarify whether one, in fact, checks the validity of the certificate that included the public key. (T-i) p. 7, Clause 2.3, l. 8 ff: same comment as T-h, but now for recipient's side. (T-j) p. 11, Clause 6, l. 4 (also l. 16): I was hoping that by now (2011), the unkeyed hash function SHA-1 would be moth-balled (rather than reintroducing this option), more than 5 years after more serious SHA-1 attacks were presented in the academic community. (T-k) p. 11, Clause 6, l. 3 (also l. 15): Why not introduce the CTR encryption mode as an option, at least when authenticity is provided? After all, CTR mode allows implementation of block-ciphers with just the forward encryption mode and offers parallelization and precomputation prospects. (T-l) General: When static-static ECDH, as specified here, stipulates checking of the certificate including the public key and that certificate is an ECDSA certificate, significant speed-ups of the computations are possible by combining the key computation step and ECDSA signature verification -- cf. http://www.ietf.org/proceedings/78/slides/saag-7.pdf. or the SAC 2010 paper referenced in that IETF-78 presentation. These results also apply here (and can obviously be ignored or embraced depending upon implementation). I would suggest adding a one-line statement that if ECDSA is used, one shall use the "friendly ECDSA" scheme as in the IETF-78 presentation (which has the same format as the ordinary one). Rene On 02/02/2011 4:55 PM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax' <draft-herzog-static-ecdh-04.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxx mailing lists by 2011-03-02. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf-announce -- email: rstruik.ext@xxxxxxxxx Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 |
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf