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

Johannes Merkle <> Fri, 04 January 2013 12:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6707721F85DF for <>; Fri, 4 Jan 2013 04:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1pHKqf-IfTjj for <>; Fri, 4 Jan 2013 04:10:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3703F21F85D0 for <>; Fri, 4 Jan 2013 04:10:05 -0800 (PST)
Received: from localhost (alg1 []) by (Postfix) with ESMTP id 65D091A0080; Fri, 4 Jan 2013 13:10:03 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from (unknown []) by (Postfix) with ESMTP id 831D61A007F; Fri, 4 Jan 2013 13:10:01 +0100 (CET)
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jan 2013 13:10:01 +0100
Message-ID: <>
Date: Fri, 04 Jan 2013 13:10:00 +0100
From: Johannes Merkle <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Andrey Jivsov <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Jan 2013 12:10:01.0356 (UTC) FILETIME=[6C0DC4C0:01CDEA74]
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: Fri, 04 Jan 2013 12:10:11 -0000

Hi Andrey,

point compression has been deleted from the draft due to the strong objections in this WG. The possibility to choose
from two distinct encodings was considered inappropriate complexity given the limited benefit.

Generally, I think that your draft has its value, albeit probably not for IKE.

Some nits:
Line 256:
   Recall that the x is an integer in the underlying finite field.
should be
   Recall that the x is an element in the underlying finite field represented by an integer.
                           ^^^^^^^                                ^^^^^^^^^^^^^^^^^^^^^^^^^
Line 352:
   When p = 4*k+3, as is the case of [SuiteB] the Brainpool curves
should be
   When p = 3 mod 4, as is the case of [SuiteB] and the Brainpool curves
            ^^^^^^^                             ^^^
Remark: Writing p = 4*k+3 is unfortunate, as k has been used to denote the private key in Section 4.2

Section 5:
   First, key pairs must be generated as defined in Section 4.2 to allow
   compact representation.
But, as you have pointed out in Section 3:
   Some protocols, such as ECDH, don't depend on the exact value of
   the y.
Thus, in these protocols, it does not matter, if the key is "compliant" or not. This should be explained, not only in
Section 5 but also in the beginning of Section 4.2.


Andrey Jivsov schrieb am 03.01.2013 08:07:
> Sorry for bringing up this so late, but I just noticed the discussion about the point compression in this thread.
> I posted the "Compact representation of an elliptic curve point"
> that I think is helpful as a generic definition of a compressed point.
> I know that -03 moved away from the compressed
> representation, but the preceding discussion is one of the reasons why I created this draft. It's unfortunate that with
> current state of ECC at IETF there is always an uncertainty/complexity such as "do we use an uncompressed point or
> compressed point; and there is IPR". There is also an issue of what's hashed and how the {x,y} is encoded. In the end in
> practice this means that there is no compression used.
> I want to add as an alternative point of view that for new features or protocols there is also a way to reduce
> complexity by using only the compact point representation, such as in
> _______________________________________________
> IPsec mailing list