Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

Tero Kivinen <> Mon, 03 December 2012 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A99B21F8715 for <>; Mon, 3 Dec 2012 04:48:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xbM0QuQu714G for <>; Mon, 3 Dec 2012 04:48:26 -0800 (PST)
Received: from ( [IPv6:2001:1bc8:100d::2]) by (Postfix) with ESMTP id 4C93C21F870D for <>; Mon, 3 Dec 2012 04:48:25 -0800 (PST)
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id qB3CluCn024163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 14:47:56 +0200 (EET)
Received: (from kivinen@localhost) by (8.14.5/8.12.11) id qB3Clt7B026301; Mon, 3 Dec 2012 14:47:55 +0200 (EET)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 03 Dec 2012 14:47:54 +0200
From: Tero Kivinen <>
To: Johannes Merkle <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 12 min
X-Total-Time: 12 min
Cc: Manfred Lochter <>, Yoav Nir <>, Dan Harkins <>, IPsecme WG <>, "" <>, "Scott Fluhrer (sfluhrer)" <>, "Sean P. Turner" <>
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange
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, 03 Dec 2012 12:48:27 -0000

Johannes Merkle writes:
> > OK, I see your point (no pun intended). Regarding ECDH secret
> > reuse, can you please review
> > That section was
> > supposed to cover the relevant security considerations. In fact I
> > think your attack is alluded to in the paper we reference from
> > that section (see Sec. 5, first paragraph).
> > 
> I agree with you that this is a general issue that should be
> addressed generally. Yet, as a precaution, I could also include such
> a requirement in the current draft.

Looking at the ECDH problems there seems to be in specifications (i.e.
what checks are needed, RFC5114 refering to wrong RFC (it should refer
to 5903 not 4753) etc, it seems we need to do something for this. I do
not think it is good idea to include this kind of things as errata.
Also I do not think we should include generic ECDH processing rules in
to the draft specifying some EC groups.

I think it would be best to take the ECDH processing rules (mostly
from 5903 but also add the checks if those are needed) and create new
RFC that will update 5996. This document should not include any

Then the question is what to do to 5114. The 5114 points to the 4753
and there is the problem that 4753 was modified with errata. This
means that 5114 is also affected by the same errata, meaning complient
implementatation should follow the same errata, i.e. the same format
that is defined in the 5903.

We should have made that 5903 to include also the 2 other groups from
the 5114, i.e. groups 25 and 26, and we really should have obsoleted
ALL ECP groups (19-21, 25-26) and allocated new numbers for all of

If that new document includes all ECDH processing rules, perhaps that
can be made to update all previous ECDH RFCs, and it can say all ECDH
curves use exactly same processing rules?