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

"Scott Fluhrer (sfluhrer)" <> Mon, 10 December 2012 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66A1C21F8558 for <>; Mon, 10 Dec 2012 13:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S50TVeVjOoZY for <>; Mon, 10 Dec 2012 13:53:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8186C21F8534 for <>; Mon, 10 Dec 2012 13:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13050; q=dns/txt; s=iport; t=1355176418; x=1356386018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=38Rq/8yOBp9V/TEo6jLptGps9Ib8Jh9fb+nUwISaGmI=; b=f25t22lQ9xqNjF0pFUkk6rwxVpv0aM9SZldAWMxbTrKyEyjKdsEE8rFg PSG1c+PmAup1k/i9+gcbdR0H8LdAqf8hfgIvkXPpAfZ3RBU2uiMPLd7rn P8lQmD26kBe0to32d3IyTp3efl8hgQtQBfZIDWMt3Gjbli/aKU1fx5Pdp g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=McAfee;i="5400,1158,6922"; a="151404788"
Received: from ([]) by with ESMTP; 10 Dec 2012 21:53:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qBALrbt0004377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Dec 2012 21:53:37 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 15:53:37 -0600
From: "Scott Fluhrer (sfluhrer)" <>
To: Hugo Krawczyk <>, Yaron Sheffer <>
Thread-Topic: [IPsec] New draft on IKE Diffie-Hellman checks
Thread-Index: AQHN1wZaPpZNcIh600ewXpvuWaXH0pgS1byA//+wE6A=
Date: Mon, 10 Dec 2012 21:53:36 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A113ACFD9DF8B04F96395BDEACB340421E4BE9xmbrcdx04ciscocom_"
MIME-Version: 1.0
Cc: IPsecme WG <>
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: Mon, 10 Dec 2012 21:53:41 -0000

From: [] On Behalf Of Hugo Krawczyk
Sent: Monday, December 10, 2012 2:50 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] New draft on IKE Diffie-Hellman checks

The tests in sections 2.1 and 2.3 are cheap and can serve as sanity checks for an implementation as stated in the draft, even if DH is not reused.

On the other hand, the test in 2.2 is expensive, equivalent to a group exponentiation, and therefore should not be recommended without DH re-use (in which case the test is an expensive waste).

Actually, the right recommendation (or MUST) for 2.2 groups is NOT to reuse DH values.
Indeed, the reason to reuse DH is to save an exponentiation but if you do so you pay with an extra exponentiation for the membership test. Moreover, while the exponentiation you are saving can be performed offline (before the run of the IKE session), the group membership test is online, so either way it makes no sense to reuse the DH exponents.
I cannot disagree with anything you say.  However, the real reason the 2.2 groups (22, 23, 24) exist is the other MODP groups do not conform to NIST SP 800-56A (see section  And, SP 800-56A also mandates the checks we recommend (section
That is, if you are implementing (say) group 24 specifically for conformance reasons, you’re going to do that test anyways (yes, it may be an expensive waste for cryptographical reasons, however, it isn’t for conformance reasons).  In that scenario, DH reuse does make sense (because not doing DH reuse doesn’t let you eliminate the test).
I would agree that maybe we need to extend the draft to discuss these noncryptographical issues.

By the way, if you forbid re-use, you need to actually mandate fresh exponents with each session (otherwise, an implementation maybe tempted to avoid re-use by using g^x, g^{x+1}, g^{x+2}, etc.)

On Mon, Dec 10, 2012 at 1:43 PM, Yaron Sheffer <<>> wrote:

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

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.


IPsec mailing list<>