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

Johannes Merkle <johannes.merkle@secunet.com> Thu, 13 December 2012 10:41 UTC

Return-Path: <Johannes.Merkle@secunet.com>
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 4877621F88C9 for <ipsec@ietfa.amsl.com>; Thu, 13 Dec 2012 02:41:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.495
X-Spam-Level:
X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 tE4RFZaBU7Yj for <ipsec@ietfa.amsl.com>; Thu, 13 Dec 2012 02:41:35 -0800 (PST)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6C021F889E for <ipsec@ietf.org>; Thu, 13 Dec 2012 02:41:34 -0800 (PST)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 471BF1A0080; Thu, 13 Dec 2012 11:41:32 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id D4AFB1A007F; Thu, 13 Dec 2012 11:41:30 +0100 (CET)
Received: from [172.16.48.110] ([172.16.48.110]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Dec 2012 11:41:30 +0100
Message-ID: <50C9B0B5.9090600@secunet.com>
Date: Thu, 13 Dec 2012 11:40:53 +0100
From: Johannes Merkle <johannes.merkle@secunet.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
References: <50C62D6A.8010709@gmail.com> <5808c090d8485cc6698829b522fade80.squirrel@www.trepanning.net> <A113ACFD9DF8B04F96395BDEACB340421E6940@xmb-rcd-x04.cisco.com>
In-Reply-To: <A113ACFD9DF8B04F96395BDEACB340421E6940@xmb-rcd-x04.cisco.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 Dec 2012 10:41:30.0717 (UTC) FILETIME=[699410D0:01CDD91E]
Cc: IPsecme WG <ipsec@ietf.org>, Dan Harkins <dharkins@lounge.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: Thu, 13 Dec 2012 10:41:36 -0000

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


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

The mapping between the registered groups and the individual subsections should be given in the appendix.


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

You are right, this is exactly what Daniel has pointed out. Unfortunately, in case of a non-trivial cofactor, the check
n*P != 0 necessary to prevent an attacker from learning (e mod h) is not cheap at all. In that case, the suggestion of
Hugo applies as well, i.e. it is better to recommend not to reuse DH keys for EC groups with non-trivial cofactor.

-- 
Johannes