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

["Dan Harkins" <[e-mail]>]

  Yaron,

  If we allocate new numbers to do it right then we will, in fact, live
forever with an ambiguous interpretation of groups 19, 20, and 21. I
agree we should fix the problem and not live with ambiguity. The proposal
to allocate new numbers doesn't seem to do that though.

  Dan.

On Mon, December 21, 2009 7:48 am, Yaron Sheffer wrote:
> 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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Tero Kivinen
> Sent: Monday, December 21, 2009 13:21
> To: Yoav Nir
> Cc: [e-mail]
> 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.
> --
> [e-mail]
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>