Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
Tero Kivinen <kivinen@iki.fi> Mon, 21 December 2009 11:21 UTC
Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5A53A680B for <ipsec@core3.amsl.com>; Mon, 21 Dec 2009 03:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC4IuxfoZhKl for <ipsec@core3.amsl.com>; Mon, 21 Dec 2009 03:21:17 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AC9A23A6848 for <ipsec@ietf.org>; Mon, 21 Dec 2009 03:21:15 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nBLBKng1029575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 13:20:49 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nBLBKlbg028183; Mon, 21 Dec 2009 13:20:47 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19247.23055.301223.938687@fireball.kivinen.iki.fi>
Date: Mon, 21 Dec 2009 13:20:47 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB36A4EC5F9@il-ex01.ad.checkpoint.com>
References: <19243.32427.247190.77844@fireball.kivinen.iki.fi> <OF1FD3CDFB.F4E96F12-ON85257690.004924DB-85257690.004AD52E@us.ibm.com> <006FEB08D9C6444AB014105C9AEB133FB36A4EC5F9@il-ex01.ad.checkpoint.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 16 min
X-Total-Time: 18 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 21 Dec 2009 11:21:24 -0000
Yoav Nir writes: > If there is such an implementation, then it's not interoperating > with all the other implementations and should be fixed. It is following the published RFC, so why should it be fixed. I think everybody agreed that making major non-interoperable change in the errata was not proper way of fixing the thing (there were lots of developers who had missed that). This whole discussion about the errata started because one implementor was implementing the RFC and wanted to make sure that the y is really added, and he wanted to make sure that he understood it correctly as that would eman that those groups cannot be made complient to FIPS 140-2. He had not noticed the errata. There were also other people who had not noticed the errata (including me). I am sure there is also people who do not follow the IPsec list and still do implement things (following IPsec list is not really requirement for implementing IPsec). I am only person in our office who regularly follow IPsec list and all others just take RFCs and read them and write code based on them. I am not sure if any of those people actually even know how to find errata... Made quick poll around the office, and found out that noboby here had checked any of the errata for any of the RFCs they have worked on. They said they usually do check for rfc-index to see if the RFC was updated or obsoleted, but that is it. > If someone shipped something like that, then the only reason they > haven't noticed yet, is because they (1) didn't test it well enough, Doing testing against your implementation does not detect that kind of problem as everything works fine. Also for quite a lot of IPsec vendors the main goal is to make implementation which works with their own products and the secondary goal is that it works with other vendor's product too. > and (2) their customers are using some other option like 1024-bit > MODP group (and 3DES, but that's beside the point) That is most likely true for all current IPsec implementations. Elliptic curves are not really used that much yet. That is the reason I want to fix this problem now, not move it to future. > Anyway, making everyone add a new group "28" just so nobody needs to > patch their old implementation of group "20" seems like wasted > effort to me. We can keep group 20, and fix the spec to prescribe > what everybody is doing anyway. I do not want to see the support request saying that our product does not interoperate vendor X's product when using group 19 and then later find out that is because the other vendor has implemented RFC4753 and didn't notice the errata. Also it will most likely take our customer and our support quite a long time before they even realize why recipient of IKE_AUTH will simply drop the packet because of wrong MAC. After that wasted effort I know that it will come to me, and I need to explain to our customer that our code is correct and the other implementation was also correct when they wrote the code, but they are not correct anymore... I do not think the elliptic curves are used that much in the current IPsec installations, so I think we still have time to fix this problem properly. -- kivinen@iki.fi
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Yaron Sheffer
- [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess … Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Scott C Moonen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Paul Hoffman
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Yoav Nir
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Yaron Sheffer
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Black_David
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Bill Sommerfeld
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Black_David
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Yoav Nir
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Jerome A. Solinas
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Dan Harkins
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Tero Kivinen
- Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve m… Jerome A. Solinas