IETF Logo Mail Archive

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

"David McGrew (mcgrew)" <mcgrew@cisco.com> Thu, 08 November 2012 21:24 UTC

Return-Path: <mcgrew@cisco.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 3DB8E21F8685 for <ipsec@ietfa.amsl.com>; Thu, 8 Nov 2012 13:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 uZVcT3bfX1iH for <ipsec@ietfa.amsl.com>; Thu, 8 Nov 2012 13:24:34 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 814EF21F84DF for <ipsec@ietf.org>; Thu, 8 Nov 2012 13:24:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2029; q=dns/txt; s=iport; t=1352409874; x=1353619474; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YmLKNutcAwmbotQQjVH3CvWZ4zGzSanUAHCP6TjUd0g=; b=hoyTd5CIwLkotAkGPUPrRcVtsWdXcI1blqGX4lPhSKxqUnP5QAIrfXAi ZDYLE7/55HihoRYlwfOTkrlbtFvN8sSSjJxdF05RaEzRJkaCGt+ZHjFXi Sj2T4/mCH5NOnJs+Imwesf2CP0xqmpLqhKh3TUi54dG5JPhd1t9sexpDv g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKcinFCtJV2a/2dsb2JhbABEw0GBCIIgAQQSASc/EgEIIhRCJQIEAQ0FCBqHaAucCaApkXhhA6RTgWuCb4IZ
X-IronPort-AV: E=Sophos;i="4.80,740,1344211200"; d="scan'208";a="140344092"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 08 Nov 2012 21:24:34 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA8LOXYi024358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 21:24:34 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 15:24:33 -0600
From: "David McGrew (mcgrew)" <mcgrew@cisco.com>
To: Johannes Merkle <johannes.merkle@secunet.com>, Tero Kivinen <kivinen@iki.fi>
Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange
Thread-Index: AQHNvYrXR2AIfdFogUKJcY2TkLUT3ZfghIcA
Date: Thu, 08 Nov 2012 21:24:32 +0000
Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F509D58@xmb-rcd-x04.cisco.com>
In-Reply-To: <509B6CC5.90407@secunet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.117.10.228]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005
x-tm-as-result: No--32.676100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A86B1B00855F9048AE4560E360371B72@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>, Manfred Lochter <Manfred.Lochter@bsi.bund.de>, "rfc-ise@rfc-editor.org" <rfc-ise@rfc-editor.org>
Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange
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, 08 Nov 2012 21:24:35 -0000

On 11/8/12 3:26 AM, "Johannes Merkle" <johannes.merkle@secunet.com> wrote:

>Hi Tero,
>
>> Every single option adds complexity, so I do not think we should add
>> more optional things.
>
>Point compression is not the focus of our draft. Given the opposition it
>is facing here, I suggest to wait for further
>replies and if point compression turns out to be objected by the majority
>on this list, I will not insist on this feature.
>BTW: In an earlier thread Dan Haskins has already indicated his
>preference to leave point compression out.
>
>> 
>> Not sending the CERT, but replacing it with hash and url offers much
>> bigger savings, and people are not even doing that.
>You can not be sure that this option isn't used is some constrained
>environments.
>
>Just a note: the relative saving of point compression is larger when
>sending hash + URL instead of the CERT.

What's the scenario here?   If hash + URL is sent, the certificate still
has to be retrieved.  It might not be part of the IKE exchange, but moving
it to HTTP doesn't mean that it doesn't contribute to bytes on the wire
(or over the air, in the case of wireless).

David

>
>> 
>> Note, that negotiating the use of point compression without retry or
>> not would waste more bytes then the point compression saves... The KE
>> payload is in the first packet, which means that to be able to
>> negotiate it beforehand would require one extra roundtrip. The IKEv2
>> headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes
>> which is already quite big EC key Y part...
>
>What I had in mind are constraint environments where using bandwidth
>saving techniques like point compression can be
>assumed to be the default.
>
>
>> If I remember right the reason IKEv2 does not use point compression
>> for the current groups was that there was some IPR. Is that issue
>> already been cleared?
>
>The the patent expires in 2014.
>http://cr.yp.to/patents/us/6141420.html
>
>-- 
>Johannes

v2.23.0 | Report a Bug | By Email