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

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Dec 2009 15:07:55 +0200

I got just request to review modifications to IKEv2 IANA because of
the draft-solinas-rfc4753bis-01.txt.

We had this discussion a while back on the IPsec list where we noted
that having errata which makes non-interoperable change to the RFC is
not really ok, and we requested the authors to submit new document.

Errata: http://www.rfc-editor.org/errata_search.php?rfc=4753&rec_status=15&presentation=records

Email thread: http://www.ietf.org/mail-archive/web/ipsec/current/msg04529.html

At that point Paul summarized things very nicely:

   My view is that the errata is technically wrong and should be
   withdrawn because it changes something that is disagreed to by test
   vectors in the document itself. If the authors of RFC 4753 want the
   format to be just the x coordinate, they should prepare a revision
   to RFC 4753 that obsoletes it and has correct text and test
   vectors.

Now when this came to me when IANA asked me to do Expert review to the
IANA allocations, I noticed that it would be very bad if we reused the
old numbers 19, 20, 21 as that would mean nobody knows which version
of the RFC (old RFC without errata, or RFC4753 with errata == new RFC)
is really used.

As the Diffie-Hellman groups are negotiated and the registry is 16
bits, we do not need to try to save the numbers, I think it would be
bad idea to reuse the existing values with different meaning. Because
of this I answered that the new groups with new meanings would need to
get new numbers.

When I started investigating problem bit more I found out that RFC5114
which defines 2 new ECP groups (in addition of repeating the 3 ECP
groups from RFC4753) says:
----------------------------------------------------------------------
3.2.  IKE

   Use of MODP Diffie-Hellman groups with IKEv2 is defined in [RFC4306],
   and the use of MODP groups with IKEv1 is defined in [RFC2409].
   However, in the case of ECP Diffie-Hellman groups, the format of key
   exchange payloads and the derivation of a shared secret has thus far
   been specified on a group-by-group basis.  For the ECP Diffie-Hellman
   groups defined in this document, the key exchange payload format and
   shared key derivation procedure specified in [RFC4753] MUST be used
   (with both IKEv2 and IKEv1).
----------------------------------------------------------------------

Now if we obsolete RFC4753, does that mean that this reference will
also change, so which format is used for these groups 25 and 26 define
in RFC5114?

Do we need a new numbers for those groups also so it will be clear
which version they use.

Then there is also the RFC4869 which defines UI suites. That refers
Diffie-Hellman groups as "256-bit random ECP group [RFC4753]". Which
format of group those uses. When we now change RFC4753 does that mean
that old implementations using RFC4869 UI suites using original
RFC4753 groups is not compatible with newer RFC4869 version or what?

I think the best way forward is to allocate new numbers for all
RFC4753 derived groups (19, 20, 21, 25, 26) and create new UI suites
using those new group numbers.

This will create one time update where everybody needs to change their
code by changing number 19 to n and 20 to n+1 and so on, and at the
same time verify that the secret they use is only the x-coordinate.
This change is small and can be done very quickly, but after that we
do not need to think whether we can interoperate with someone using
ECP group n, as we know it must be using new secret format.

If someone uses old groups 19, 20, 21, 25, or 26 then you can make
your guess whether they also implemented errata or not, and act based
on that. Good thing is that as Diffie-Hellman groups are negotiated in
IKEv2 it is easy to offer both 19 and new group n if backward
compatibility with old versions is needed (provided you also know
whether the group 19 on the other end uses errata or not). 
-- 
[email-masked]

---

From: Scott C Moonen <[email-masked]>
Date: Fri, 18 Dec 2009 08:37:25 -0500

Tero, what you propose seems the right way to go in principle, but I 
suspect we are solving a problem that doesn't exist.  Is there any crypto 
library or device that exposes the y coordinate for use in the ECDH 
secret?  It seems pretty well established that the x coordinate serves as 
the ECDH secret.  Moreover, since the y coordinate provides only one more 
bit of independent information, it's actually misleading to use it.

I seriously doubt there is any implementation that does not implement the 
intent of the erratum, if only because there are immense practical 
barriers to implementing the RFC as written.  Given that, I think the 
practical result of what you propose will actually be more confusion and a 
longer period of time before all implementations (as well as all 
standards/profiles) are able to re-stabilize to the new ECDH landscape. 
The practical cost of making this change is greater than the practical 
benefit it buys.

On the other hand, if there is such an implementation, then we probably do 
need to do something like what you propose.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
[email-masked]
Date:
12/18/2009 08:08 AM
Subject:
[IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, 
RFC4869, and draft-solinas-rfc4753bis-01)

Errata: 
http://www.rfc-editor.org/errata_search.php?rfc=4753&rec_status=15&presentation=records

Email thread: 
http://www.ietf.org/mail-archive/web/ipsec/current/msg04529.html

If someone uses old groups 19, 20, 21, 25, or 26 then you can make
your guess whether they also implemented errata or not, and act based
on that. Good thing is that as Diffie-Hellman groups are negotiated in
IKEv2 it is easy to offer both 19 and new group n if backward
compatibility with old versions is needed (provided you also know
whether the group 19 on the other end uses errata or not). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 18 Dec 2009 11:01:09 -0800 (PST)

Hi Scott,

  I agree. The errata is not technically wrong. That's the way ECDH
is defined in ANSI X9.63, and SEC1, and FIPS 800-56A and that's the
way every crypto library that I'm aware of produces the shared secret.
I don't think this is problem has manifested itself in implementation
non-interoperability, it's just document non-interoperability.

  I think it would be better to just obsolete RFC 4753 and update
RFC 5114 (to not refer to RFC 4753 and have _correct_ test vectors
producing Z = x_Z as the result of the ECDH), and update RFC 4869
to refer to the updated RFC 5114. Then the IANA registry should indicate
that the updated RFC 5114 defines these groups.

  The solution of allocating new numbers still doesn't really solve the
problem because if you receive an KE payload from group 19, 20, or 21
"you can make your guess whether they also implemented errata or not,
and act based on that" and that sounds like a recipe for future
non-interoperability.

  The IANA registry for these groups is used by more than just IKE(v2)
and it would be nice if it was coherent and did not make assumption like
that.

  regards,

  Dan.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Dec 2009 23:05:55 +0200

If there is such an implementation, then it's not interoperating with all the other implementations and should be fixed.

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, and (2) their customers are using some other option like 1024-bit MODP group (and 3DES, but that's beside the point)

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.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Scott C Moonen [[email-masked]]
Sent: Friday, December 18, 2009 15:37
To: Tero Kivinen
Cc: [email-masked]; [email-masked]
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

Tero, what you propose seems the right way to go in principle, but I suspect we are solving a problem that doesn't exist.  Is there any crypto library or device that exposes the y coordinate for use in the ECDH secret?  It seems pretty well established that the x coordinate serves as the ECDH secret.  Moreover, since the y coordinate provides only one more bit of independent information, it's actually misleading to use it.

I seriously doubt there is any implementation that does not implement the intent of the erratum, if only because there are immense practical barriers to implementing the RFC as written.  Given that, I think the practical result of what you propose will actually be more confusion and a longer period of time before all implementations (as well as all standards/profiles) are able to re-stabilize to the new ECDH landscape.  The practical cost of making this change is greater than the practical benefit it buys.

On the other hand, if there is such an implementation, then we probably do need to do something like what you propose.

From:   Tero Kivinen <[email-masked]>
To:     [email-masked]
Date:   12/18/2009 08:08 AM
Subject:        [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

________________________________

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Dec 2009 13:20:47 +0200

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. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Dec 2009 14:01:04 +0200

> bit of independent information, it's actually misleading to use it.

At least in our crypto library it would be possible to get both of
them out if we wanted. I checked our implementation and currently it
seems to return only x, but that was changed July 2009 after this
dicussion started on the list. Before that the code was modified in
2007 to follow RFC4753, and the original code was written in 2001.

This means that all our implementations we have released between
2007-2009 are using the orignal RFC4753 version, thus nobody will be
interoperable with those.

> The practical cost of making this change is greater than the practical 

There are as all our QuickSec implementations with versions 4.4 - 5.0
do include the original RFC 4753 code, and only the latest QuickSec
5.1 was modified to include errata.

(I just now noticed this myself).

Note, that none of our customers have complained to us that we are not
compatible with other vendor's product using groups 19-21, so that
either means nobody uses those groups, or some of those other vendors
have also implemented RFC4753 without errata... 

> need to do something like what you propose.

As we need to do something on those versions anyway, I rather make
patch that will fix them to follow the new RFC, and also change the
group numbers to match new group numbers for those old versions, as
then customers using those versions will not break their own
interoperability with old versions (it is ok, if they decide to select
some other Diffie-Hellman group as old versions do not support new
numbers, but it is not ok for the implementations to get MAC failures
when trying to use those groups). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 21 Dec 2009 14:05:26 +0200

> and act based on that" and that sounds like a recipe for future

As I just noticed we do support RFC4753 without errata in our previous
versions we need to do something on this. What my current plan would
be to make patch that will change implementations to support errata,
and also change the group numbers to new. This means you get no
proposal support or invalid ke payload notification if you try to talk
to old versions supporting groups 19-21. If the policy allows any of
the modp groups then invalid ke payload error cause both ends to move
to modp groups which means implementations can talk to each other, and
if policy only allows those new groups then you get no proposal chosen
and then you need to modify policy to support some common groups. 

> and it would be nice if it was coherent and did not make assumption like

ikev2-parameters IANA registry should not be used for anything else
than IKEv2. 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Dec 2009 17:48:18 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Tero Kivinen
Sent: Monday, December 21, 2009 13:21
To: Yoav Nir
Cc: [email-masked]
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

Scanned by Check Point Total Security Gateway.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 21 Dec 2009 10:42:05 -0800 (PST)

No, you won't get "no proposal chosen" or "invalid KE" payload.
What you'll get, if you "guess" wrong, is garbage IKEv2 messages
because a different representation of the shared secret will be fed
into the prf that generates the keying material. That will not be
diagnosable. Things just won't work and the customer will get really
mad. And if developers aren't reading errata (as you claim) then I
seriously doubt that field engineers and support do either. So we're
looking at an RMA of a perfectly good piece of equipment.

  Your suggested fix does not actually fix the existing problem, it
just makes an unambiguous way to negotiate these groups using different
numbers. The same ambiguity will still exist for 19, 20, and 21.

  I think it would be better to fix the problem. You mentioned to Yoav
that EC groups are not used that much currently. So this is an opportune
time to fix the problem!

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 21 Dec 2009 10:43:32 -0800 (PST)

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
>
> Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753,
> RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)
>
> Yoav Nir writes:

---

From: <[email-masked]>
Date: Mon, 21 Dec 2009 13:54:12 -0500

Dan,

> 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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Harkins
> Sent: Monday, December 21, 2009 1:44 PM
> To: Yaron Sheffer
> Cc: [email-masked]; Yoav Nir; Tero Kivinen

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 21 Dec 2009 11:48:19 -0800

As an additional datapoint: 

We (Dan McDonald and I) recently extended our IKEv1 implementation to
include ECDH groups 19, 20, and 21 as well as the 5114 groups, over a
cryptographic library which only makes the "x" coordinate available. 

The as-specified behavior is unimplementable using the public interface
to the library we have available to us.

While I have not been following this list closely, I found the errata
and associated discussion.

This code is not yet in a publicly available build of Solaris but we've
interoperated with groups 19 and 20 with a publicly available product
build of one other implementation so far (worked on the first try) and
wouldn't mind a little more interoperability testing before letting it
escape into the wild.

I believe the errata is clear and there is enough of a critical mass of
implementations doing it correctly (x value only) that it's not
necessary to deprecate the existing codepoints.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 21 Dec 2009 12:53:12 -0800 (PST)

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, [email-masked] wrote:
>> > From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of
>> > Tero Kivinen

---

From: <[email-masked]>
Date: Mon, 21 Dec 2009 16:03:19 -0500

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

> Sent: Monday, December 21, 2009 3:53 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Black, David
> >> Of Dan Harkins

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 22 Dec 2009 00:03:06 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 21, 2009 23:03
To: [email-masked]
Cc: [email-masked]; Yoav Nir; [email-masked]
Subject: Re: [IPsec] IKEv2 Diffie-Hellman Elliptic curve mess (RFC4753, RFC5114, RFC4869, and draft-solinas-rfc4753bis-01)

Dan,

Thanks,
--David

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 21 Dec 2009 14:41:50 -0800 (PST)

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
>
>> >> > problem now by allocating a few more numbers, than live forever
>> with
>> >> an

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Dec 2009 09:46:12 +0200

> That should avoid long term problems.

No, this will solve the problem in the long term. In the short term, there are things like Windows 7 out there that already use group 19 and group 20 (and they only send x). For the vendor to follow your obsolescence plan, they would need to have a patch that replaces the use of 19 and 20 with, say, groups 27 and 28. That would mean breaking interoperability with the old unpatched Windows 7, plus all other implementations out there (there is even less running code for groups 19 and 20). So a vendor would have to support both group 19 (wrong or right interpretation) and group 27 (hopefully only one right interpretation) 

> one coordinate is used, we might not have a problem in practice.

Well, both Tero's company and mine have people who follow this list, and yet both companies made this mistake. "People just knowing" failed". Luckily for us, this running code was not yet released when they discovered the issue, so we don't have a support/upgrade problem. The real issue is with running code that's both broken and out there. Unfortunately, we can't rely on all developers on ECDH code being on this list. The mitigating factor is that those who implement by using OpenSSL code will run into the fact that OpenSSL APIs only give you the x coordinate, unless you supplement their code with your own function  that gets the y coordinate.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Dec 2009 12:08:01 +0200

> looking at an RMA of a perfectly good piece of equipment.

If we allocate new numbers and change to use them, then you DO get no
proposal chosen and invalid IKE payloads. What you explaining there is
what happens now when someone tries to use those ecp groups between
two implementations which do not agree on errata or not. 

> numbers. The same ambiguity will still exist for 19, 20, and 21.

Yes, but all of those groups are marked "OBSOLETED" or "Reserved (was
xxx)" in the iana-registry, and the RFC4753 is also osboleted by the
new rfc.

Then I would also propose all implementations out there that when they
change from numbers 19, 20, 21, 25, 26 to new numbers, they will
either remove the old numbers completely (as there is no way to get
interoperability with them), or at least add warnings to them saying
that those groups might not be interoperable.

> that EC groups are not used that much currently. So this is an opportune

EC groups are not used right now, but the implementations we have put
out in the last 2 years are going to be out there for long time, and
all of those will use the wrong version. I want to make sure that new
versions we push out will make fail cleanly (i.e. with no proposal
chosen or invalid ke payload) when talking to those old versions. This
happens, because the new versions do not support groups 19, 20, 21,
25, 26 at all, but only the new ones, and with those new numbers there
is no ambiguity how they are processed. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Dec 2009 12:13:00 +0200

> That should avoid long term problems.

Yes. Exactly that was what I was trying to say, except same thing also
needs to be done for RFC5114, as it refers to RFC4753, and perhaps
also RFC4869 as it also refers to RFC4753. 

> an actual "running code" problem before doing something this drastic.

As I said QuickSec versions 4.4 - 5.0 (i.e. QuickSec versions released
between 2007-2009) do include original RFC4753 code, the person who
fixed our code to support RFC4753 didn't notice the errata...

As our OEM toolkit is used quite widely I think there are quite a lot
of existing products doing things without errata. Also most of those
people (our customers) are not reading this list.

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Dec 2009 12:22:40 +0200

Dan Harkins writes:
> product from outside that window, either before or after.

Yes. 

> And that problem will not go away by defining new numbers.

It does, as if none of the new versions include support for those
groups at all using those numbers (as they are obsoleted), then those
old unpatched versions are getting policy mismatch instead of MAC
failures, and they can fix their policy to use MODP groups.

> existing specification.

No, as every time one of those new implementations talks to old
implementation following RFC4753 without errata, there will be MAC
failure which is hard to diagnostic.

If new version does not ever include old ECP group numbers in their SA
proposals, there is no way new versions and old versions could even
try to negotiate ECP groups, thus they would fall back to modp groups,
or at least get people to ask correct question, i.e. why the new
version removed ECP groups 19, 20, 21, 25, 26 and then vendor would
answer: "because they are obsoleted and replaced with groups n ..
n+m". 

> that those implications are likely to be minor (and possibly non-existent).

EC groups are not used, but the implementations are already out there,
and some day someone might actually enable them in their policy, and
if we do not allocate new numbers we are going to get those problems
in the future. Those products using QuickSec OEM toolkit 4.4 - 5.0 are
not going to disappear, and those products will nicely interoperate
with each other.

We can provide them fix to the old products, but that does not mean
our customers will actually put that to their products, and some of
those products (ADLS boxes etc), might be something they will not
provide updates at all. 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Dec 2009 13:52:24 -0500

First off, thank you for bringing the topic to the WG. As the Designated Expert, you are certainly allowed to make decisions without asking, so it is extra nice that you ask on decisions that might be controversial.

On this particular topic, I would note that RFC 4753 is Informational RFC, not a standards-track document. Thus, I would think that desires of the authors of the RFC should have a heavier influence than the rest of us, although our input might be important inputs to them (and maybe to the Designated Expert). Maybe we should put the issue aside until we hear from them, which could be after the holiday.

--Paul Hoffman, Director
--VPN Consortium