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

"Dan Harkins" <> Thu, 13 December 2012 22:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75CE221F8B11 for <>; Thu, 13 Dec 2012 14:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.19
X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yd78WBmJ0xJe for <>; Thu, 13 Dec 2012 14:58:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AC5BF21F8B0C for <>; Thu, 13 Dec 2012 14:58:58 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 211701022400A; Thu, 13 Dec 2012 14:58:57 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Thu, 13 Dec 2012 14:58:58 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 13 Dec 2012 14:58:58 -0800
From: Dan Harkins <>
To: "Scott Fluhrer (sfluhrer)" <>
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 <>, Johannes Merkle <>, Dan Harkins <>
Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Dec 2012 22:58:59 -0000

On Thu, December 13, 2012 7:57 am, Scott Fluhrer (sfluhrer) wrote:
>> -----Original Message-----
>> From: Johannes Merkle []
>> Sent: Thursday, December 13, 2012 5:41 AM
>> To: Scott Fluhrer (sfluhrer)
>> Cc: Dan Harkins; Yaron Sheffer; IPsecme WG
>> Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks
>> > 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.
>> Why not keeping the main document general and giving details for
>> registered groups in an appendix?
> Hmmmm, I like that suggestion.

  That's a great suggestion. Yaron also mentioned the idea of adding
a note column to the DH group repository that references the particular
section of your draft (instruct IANA to update the registry with the section
and the RFC number that gets assigned to your draft). I think both of
those would be good.

> Here's what I'm wrestling with; every curve that we currently support
> (and, in fact, every prime curve I've heard anyone suggest) has h=1
> (having h>1 makes the discrete log problem be a factor of sqrt(h) easier,
> for no benefit that I can see); hence, this cofactor test is moot.  So, do
> we complicate our description (at least, of the prime curve section) with
> a test that never really applies?

  Maybe not. It might make sense to say that all the curves have an
implied co-factor of 1 though.

> Now, if we do have a section covering even characteristic curves, those
> have h>1 (the math pretty much forces that), and so a discussion there
> wouldn't be entirely out of place.  On the other hand, there are
> standardized ways of defining the ECDH operation so that the cofactor
> doesn't cause any leakage ("ECC CDH", where the shared secret really is
> hxyG); if the group is defined using that primitive, such a cofactor test
> beforehand is unneeded.  Will such a group use such a modified DH
> operation?  Well, given that no such groups are currently defined, we
> can't say.
> My opinion: in the prime curve section, there's no reason to mention a
> cofactor; and that it's premature to put in an even characteristic curve
> section.

  OK, I agree with the former, but why not just cover all the possibilities
by  mentioning the characteristic curves? It's supposed to be a forward-
looking document that's placing requirements on future RFCs that add
new groups and there's no reason why someone couldn't add such a curve.
I think it would be cleaner to have everything covered here instead of
having this one mention 3 of 4 and another RFC mention the 4th.