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

"Dan Harkins" <dharkins@lounge.org> Tue, 11 December 2012 18:06 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF921F8703 for <ipsec@ietfa.amsl.com>; Tue, 11 Dec 2012 10:06:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.205
X-Spam-Level:
X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqLDp5ZQsiPz for <ipsec@ietfa.amsl.com>; Tue, 11 Dec 2012 10:06:06 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 722BA21F86E4 for <ipsec@ietf.org>; Tue, 11 Dec 2012 10:06:06 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AA4C310224008; Tue, 11 Dec 2012 10:06:05 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 11 Dec 2012 10:06:06 -0800 (PST)
Message-ID: <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net>
In-Reply-To: <50C62D6A.8010709@gmail.com>
References: <50C62D6A.8010709@gmail.com>
Date: Tue, 11 Dec 2012 10:06:06 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2012 18:06:07 -0000

  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
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>