comments on <draft-harkins-brainpool-ike-groups-04.txt> (Brainpool Elliptic Curves for the IKE Group Description Registry)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]