Re: [IPsec] New draft on IKE Diffie-Hellman checks

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

Maybe we should talk about who the audience of this RFC ought to be.

I'm positing an audience of people who know little about elliptic curves; they have no idea about what a cofactor or a Sophie-Germain prime is.  All they're interested in is trying to implement this protocol in a secure manner, and want to dig into the mathematical details as little as possible.

With that in mind, I have comments below:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Dan Harkins
> Sent: Tuesday, December 11, 2012 1:06 PM
> To: Yaron Sheffer
> Cc: IPsecme WG
> Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
> 
> 
>   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

And what's a Sophie-Germain prime?  Yes, I know (and definition you're using is not the definition that Ms. Germain originally gave it); however, a random implementor is unlikely to.

The reason I put the group numbers in the titles is to make it easier for an implementer to decide, for a specific group, which section is appropriate.  Perhaps another approach for achieving that goal would be better.

>      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.

RFC5903 doesn't list the value of 'a' for those curves; that's why I listed it here.  I don't believe it is appropriate to send someone to a document which doesn't list the details we say it lists.

> 
>   - 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

This is a cheap check (if h=2, I believe that's just a check that a coordinate != 0, and as you say below, it's even cheaper if h=1).  However, is there a specific attack that is possible if you don't do the check?  If you're worried about someone modifying the DH public value with this value, IKE already has protections against that in place.  If you're worried about someone learning the value of (e mod h) (where e is the private ECDH multiplier), this check doesn't prevent that.

> 
>      Add this check to both 2.3 and 2.4. Of course if h=1 then this
>      check can be skipped.

Neither RFC5114 nor RFC5903 list the value of the cofactor for the curves it defines.  How then do we expect someone to implement the test if they don't know that already?

Remember the goal; keep things simple for the implementor.  Yes, this cofactor test is cheap; however, if that check doesn't actually prevent an attack, I'd prefer that we don't make the implementor worry about it (especially since it asks for a detail that isn't listed in the RFCs that defines the curves)

> 
>   - 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> 
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec