On Wed, July 18, 2012 5:14 pm, Tero Kivinen wrote: > Dan Harkins writes: >> Nobody said anything about "adding everything". That is a complete >> straw >> man argument. In fact, it is decidedly not the case that "everything" is >> being >> added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so >> quick >> to leap to unfounded conclusions you would see this IANA update as the >> innocuous event that it really is. > > Not if you count the authentication methods in to it too. That do > require quite a bit of work to make sure everything is done correctly. > > Especially as IKEv1 exchanges are quite different depending which > authentication method is used. Adding only the Diffie-Hellman groups > is much easier, but I understood that the idea was to add both. > > And for SPSK there was also text for adding that to IKEv1 too, before > it was removed. Same is now with the ike-over-tcp, which again has > IKEv1 text in it.
EXACTLY!!! That is what I was saying. "everything" is not being added to IKEv1 and we have documented evidence, you even provided another example. So your statement that this innocuous addition of code points to a registry is somehow "adding everything" is just hyperbole. >> This is allowing existing implementations to have more flexibility in >> the >> ECDH operations they perform to comply with various requirements that >> may exist in different locales or in different circumstances or >> situations. > > I would think the ECP groups we already have in the IKEv1 should be > enough for the most common case, i.e. the suite-b uses. Also I still > do not think that many implementations are going to update their IKEv1 > implementations. The brainpool curves have been defined for a purpose that, apparently, the NIST-defined curves does not satisfy. And your statement about "many implementations" is belied by your behavior. Why would someone be such a vocal advocate of a law that is not necessary? [snip] > So what is wrong with using the already existing mechanisms of using > groups directly in the SA for that already obsoleted protocol? It > seems the only reason to add numbers for them is to support non IPsec > use... They are for the situations in which the brainpool curves are necessary. That is not "to support non-IPsec use". That is not why the brainpool curves were defined. >> > This is exactly why new group mode was made a SHOULD in the IKEv1, >> > i.e. to allow adding new groups without need to changing the >> > specification or the actual code. >> >> Your recollection differs from the person who actually wrote the RFC. >> And when that happens one should typically defer to the author. In fact, >> your statement seems to differ from the RFC which says it SHOULD be >> supported as a mechanism to define "private groups". The brainpool >> groups are not private and there is no reason to treat them as such. > > Brainpool groups do not have number in the IANA registry, which makes > them private for IKEv1 use. There is nothing there claiming that you > can only use new group mode to negotiate groups that are not know for > anybody else. "Brainpool groups do not have a number in the IANA registry". What do you think the topic of this thread is? Look at the subject above. You are arguing against doing something because it hasn't been done yet and that is illogical. You know what? IKEv2 doesn't have any brainpool groups defined in its IANA registry. Are you against such a code point allocation? If not, then can I please ask you to be consistent in your positions? [snip] > I have never tried to hide the fact that I think IKEv2 is much better > protocol than IKEv1. IKEv1 do have some security problems (not big > enough to cause it to fail completely, but they are there). IKEv1 does > not have standardized support for many things that are there for > IKEv2. Many IKEv1 implementations uses methods described in the > expired Internet-drafts for some things, and there are multiple of > those methods different implementations use. > > I think IKEv1 needs to DIE. It is so broken I see no reason for it to > kept alive anymore. I do not want anybody to add anything to it for > two reasons: > > 1) I am the implementor who might need to implement them in our code. > Up to this point I have been able to say we do not want to do any > changes to IKEv1 code. > 2) It might make people feel like IKEv1 could still be used. > > This is my opinion and I do stick to it, and I do continue trying to > convince others to it too. I see no problem there. > > Are you saying that I am not allowed to try to do what I belive is > right? No, if you read what I said I wished you luck in your advocacy that people should stop using IKEv1. I'm not trying to stifle you, I'm saying that it is inappropriate to make life a programmatic hell for other people just because you, personally, want IKEv1 to die. >> > We do not need to keep adding features to the old obsoleted protocoles >> > either. >> >> This is NOT a feature. ECDH already exists in IKEv1. This is allowing >> existing implementations, of which they are legion, to use certain >> domain parameter sets that may be required or desired in certain >> situations >> and in certain locales. > > Anything that changes the code in implementations needs to be > categorized in two ways, i.e. either they are: > > 1) Bugs > 2) Enhancements / new features > > I do not consider this to be bug, so it is new feature / enhancement > to the IKEv1. If an implementation is well-written it would not require ANY changes to the implementation. It would require a domain parameter set definition (probably in a .h file) and an associated magic number. Recompile. Voila. > Especially as there is already a way (actually 2 ways) to do the same > thing in the standard IKEv1 protocol. Both of which are programmatically problematic and have security issues (checking the brainpool curves if added to the SA payload or in New Group Mode would, most likely, require changes to code. Furthermore, not all implementations support domain parameter sets being passed in SA payloads (do any?) or New Group Mode so what you are advocating for causes more of the problems you are trying to use to justify your advocacy. [snip] > But I think we are quite far now from where this dicussion started, > and I am not sure if it is useful to continue this discussion as we > simply disagree whether IKEv1 should die or not. Regrettably, yes we are quite far from where this started. Straw men and circular arguments tend to do that. IKEv1 can die, I just don't see a reason to suffocate it. People use it every day (I'm using it right now!). Different people have different requirements (hence the definition of brainpool curves). You want to force people to do something they don't currently want to do by making artificial impediments to code. It really is not appropriate to use standards bodies in this manner. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
