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

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

  My understanding of Tero's mail is that the code was originally written
in 2001. It was modified sometime in 2007 to add "y". Then in July 2009
it was changed to not add "y". So I think there is a problem for a product
shipped from sometime in 2007 to July 2009 when it interoperates with
product from outside that window, either before or after. And that problem
will not go away by defining new numbers.

  We are going to have unconditional interoperability for new
implementations whether we define new numbers or just clean up the
existing specification. And we are going to have some potential (but
probably very small) interoperability issues for product that implemented
RFC 4753 without the errata whether we define new numbers or just clean
up the existing specification. So defining new numbers doesn't really
change anything and it leaves some weird and inexplicably unique handling
of an ECDH shared secret in the specification-- groups 19 and "n" have
identical parameters but with 19 you use x||y and with "n" you just use x.

  I think most everyone agrees that elliptic curve groups aren't really
used today so the problem can be resolved by fixing the documents. Yes,
the errata introduces interoperability implications, so let's be happy
that those implications are likely to be minor (and possibly non-existent).

  Dan.

On Mon, December 21, 2009 2:03 pm, Yaron Sheffer wrote:
> My understanding of Tero's mail is that *he* has such running code.
> Defining the new numbers would leave these old implementations in the
> lurch, but would ensure unconditional interoperability for new
> implementations.
>
> Thanks,
> 	Yaron
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Monday, December 21, 2009 23:03
> To: [e-mail]
> Cc: [e-mail]; Yoav Nir; [e-mail]
> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753,
> RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
>
> Dan,
>
> I'm inclined to concur with Bill Sommerfeld and you that we don't have
> a "running code" problem, but my original email suggests what could
> be done to retire the old identifiers _if_ we did have such a problem.
>
> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Dan Harkins
>> Sent: Monday, December 21, 2009 3:53 PM
>> To: Black, David
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; Black, David
>> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753,
>> RFC5114, RFC4869, and draft-
>> solinas-rfc4753bis-01)
>>
>>
>>   Hi David,
>>
>>   I don't believe there is an actual "running code" problem. It's
>> just a documentation problem and the errata corrects it.
>>
>>   The thing is, _if_ a running code problem exists the proposal to
>> add new identifiers for the exact same ECP definitions would not fix
>> it.
>>
>>   Dan.
>>
>> On Mon, December 21, 2009 10:54 am, [e-mail] wrote:
>> > Dan,
>> >
>> >>   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.
>> >
>> > Fine, here's how to accomplish that goal - the RFC that allocates
>> > the new group numbers should:
>> >   1) explain why the group numbers 19, 20 and 21 are ambiguous;
>> >   2) state that group numbers 19, 20 and 21 "SHOULD NOT be used";
>> >   3) instruct IANA to remove the group number registrations for
>> > 	19, 20 and 21 in a fashion that prevents reallocation; and
>> >   4) obsolete RFC 4753.
>> > That should avoid long term problems.
>> >
>> > That said, I'd like to see more reason to believe that there is
>> > an actual "running code" problem before doing something this drastic.
>> > If most people working with elliptic curve "just know" that only
>> > one coordinate is used, we might not have a problem in practice.
>> >
>> > Thanks,
>> > --David
>> > ----------------------------------------------------
>> > David L. Black, Distinguished Engineer
>> > EMC Corporation, 176 South St., Hopkinton, MA  01748
>> > [phone]             FAX: [phone]
>> > [e-mail]        Mobile: [phone]
>> > ----------------------------------------------------
>> >
>> >> -----Original Message-----
>> >> From: [e-mail] [mailto:[e-mail]] On
>> Behalf
>> >> Of Dan Harkins
>> >> Sent: Monday, December 21, 2009 1:44 PM
>> >> To: Yaron Sheffer
>> >> Cc: [e-mail]; Yoav Nir; Tero Kivinen
>> >> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess
>> (RFC4753,
>> >> RFC5114, RFC4869, and draft-
>> >> solinas-rfc4753bis-01)
>> >>
>> >>
>> >>   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
>> >> >
>> >>
>> >>
>> >> _______________________________________________
>> >> IPsec mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/ipsec
>> >
>> > _______________________________________________
>> > IPsec mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ipsec
>> >
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
> Scanned by Check Point Total Security Gateway.
>