Dear Dan:
I have the following (minor) comments on drat-harkins-brainpool-ike-groups:
Section 2:
(E-1) RFC 5639 specifies BP-160, BP-192, BP-224, BP-256, BP-360, BP-384,
BP-512, including domain parameters and relationship between the twisted
curve and the curve (via the "Z" parameter), in a concise and clear
manner. Thus, this section seems superfluous and can simply refer to
forementioned RFC.
(E-2) BSI (added reference of 2012 -- see comment below) recommends the
use of Brainpool curves of bit-length at least 224 bits and may have
uses for the BP-360 curve. The current draft, however, suggests not to
include BP-360, due to "non-matching" current hash functions. With
SHA-3, this may certainly change. Moreover, since the draft does not
stipulate the context in whih the Brainpool curves are to be used (as
also evidenced by Section 4), it seems to be somewhat premature to be
this restrictive.
Section 3:
(E-3) The draft's purpose seems to be self-contradictory, since
according to Section 1, the intention is to add codepoints in RFC 2409,
while Section 3 explicitly forbids its use. To add to the confusion,
Section 5 explicitly makes this objective self-defeating (see
"administrative Verbot" language).
Section 4:
(E-4) l. 4: replace "crryptography" by "cryptography"
(T-1) Brainpool curves have order q, that is not "close" to a power of
two, thus making both generation of random scalars in the interval
[1,q-1] more difficult and increasing implementation cost (e.g., with
modular reductions). This suggests that, although Brainpool curves have
"interesting security properties" (as mentioned in Section 1), they also
have some properties that may give some reason for practical reflection.
Shouldn't one expand somewhat on how one could securely generate a
number in the [1,q-1] interval and, e.g., whether Brainpool curves
differ from NIST prime curves in implementation security vulnerabilities?
NOTE - Since the draft simply defines the use of certain Brainpool
curves, one may also push these topics "under the rug" and make almost
the entire draft a cross-reference to RFC 5639. (It does not address
these points, but then neither does RFC 5639 entirely.
Section 6.2:
(E-5) Please add the following informational reference: Bundesamt fur
Sicherheit in der Informationstechnik, Technical Gideline TR-03111 -
Elliptic Curve Cryptography, Version 2.0, June 28, 2012.
On 1/31/2013 9:12 AM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Brainpool Elliptic Curves for the IKE Group Description Registry'
<draft-harkins-brainpool-ike-groups-04.txt> as 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 2013-02-28. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This memo allocates code points for four new elliptic curve domain
parameter sets over finite prime fields into a registry that was
established by The Internet Key Exchange (IKE) but is used by other
protocols.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-harkins-brainpool-ike-groups/ballot/
No IPR declarations have been submitted directly on this I-D.
--
email: rstruik.ext@xxxxxxxxx | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363