Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

Hi Tero,

I support your position (and disagree with Yoav). We had better fix this problem now by allocating a few more numbers, than live forever with an ambiguous interpretation to the numbers that everybody's using.

Thanks,
	Yaron

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen
Sent: Monday, December 21, 2009 13:21
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.