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.
<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
<http://www.inderscience.com/browse/index.php?journalID=233&year=2010&vol=2&issue=2>
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(_at_)ietf(_dot_)org mailing lists by 2011-03-02. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
--
email: rstruik(_dot_)ext(_at_)gmail(_dot_)com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf