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

[Rene Struik <[e-mail]>]

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
> [e-mail] mailing lists by 2013-02-28. Exceptionally, comments may be
> sent to [e-mail] 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: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]