Hello,
I have a few comments.
- The Introduction says that "It turns out using EC groups in
some scenarios require...additional tests. This document
defines these tests." Well the memo is defining more than
EC. I think the Intro should introduce us to the why, which
is sort of mentioned in the next section. It would be better
to state in the Intro that the memo is defining group
membership tests to apply to DH values received during
IKEv2. Then let section 2 have normative text for what's
REQUIRED and what's RECOMMENDED and set up the reason
for the sub-sections-- i.e. different kinds of DH groups have
different kinds of group membership tests.
- The IANA considerations imply that this is placing requirements
on future RFCs. That being the case, I think the subsections
of section 2 should not be so group-number-specific, e.g.
today's group numbers should not be in the subsection titles.
I'd suggest:
2.1 MODP Groups Based on Sophie-Germain Primes
2.2 MODP Groups With a Small Sub-Group
2.3 Elliptic Curve Groups Over a Prime Finite Field
and then in each of them you say what the group membership
test is and only then say that as of publication of this memo
the following groups are covered by this section...list the group
numbers.
This will allow, for example, Johannes' draft to say that the
membership tests for the groups it is defining are in section
2.3 of RFCXYZ and that section heading won't say "groups
19-21, 25, 26" which would be somewhat clumsy.
Also, don't say that a=-3 in 2.3. Just say that a, b, and p are
from the domain parameter set defining the group. I think it's
better to just define the test, let the reader get a, b, and p.
- I'd also suggest a sub-section like this:
2.4 Elliptic Curve Groups Over a Characteristic-2 Finite Field
And the check is that the x- and y-coordinates are binary
polynomials of degree m-1 (where m is field size of the curve)
and that:
y^2 + xy = x^3 + ax^2 + b (in GF(2^m))
I know that the binary curves in RFC2409's registry were
removed from the RFC5996's registry but some may be defined
in the future and it would be good to cover all the possibilities
now.
- I think it should be mentioned that elliptic curve groups
have a co-factor, h, and if h > 1 that a further check is
also required, namely, if the x- and y-coordinates define
a point Q then ensure that:
hQ = point-at-infinity
Add this check to both 2.3 and 2.4. Of course if h=1 then this
check can be skipped.
- Let IANA know what registry these new requirements are
being place on. It says, "The groups mentioned here are managed
by IANA." I suggest adding "in [IKEV2IANA]." and add the following
in the References:
[IKEV2IANA] Internet Assigned Numbers Authority, "Internet Key
Exchange Version 2 (IKEv2) Parameters", Transform
Type 4-- Diffie-Hellman Group Transform IDs.
regards,
Dan.
On Mon, December 10, 2012 10:43 am, Yaron Sheffer wrote:
> Hi,
>
> following the recent discussion on the mailing list, Scott Fluhrer and
> myself just published a draft that updates RFC 5996 by adding the
> required recipient-side tests for ECDH. Please see
> http://www.ietf.org/internet-drafts/draft-sheffer-ipsecme-dh-checks-00.txt.
>
> We have not addressed the issues raised by Dan and Tero regarding
> inconsistencies between various RFCs that define ECDH groups for IKE. I
> personally deem these issues to be out of scope of the current document.
>
> Comments are very welcome.
>
> Thanks,
> Yaron
>
> _______________________________________________
> IPsec mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
