[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Son-of-IKE Performance

On Fri, 07 Dec 2001 20:54:19 EST you wrote
> 
> Dan -- if we were about to issue "Last Call" on JFK, I'd not only agree 
> with you, I'd be leading the charge.  We're not nearly at that stage 
> yet.  The purpose of the JFK draft was to describe a cryptographic 
> protocol, not (yet) an implementation spec.  Clearly, there are many 
> ways to derive the four needed keys from the one exchange; equally 
> clearly, a final spec *must* specify exactly one, in very precise form. 
> If and when the WG agrees on JFK, we'll happily fill in those details.

I would hope all the details (not just this one) were filled in before
a decision is made. That's a little like buying a house sight unseen. The
floorplan is what I wanted but the roof leaks, the doors don't close all
the way, and a fuse is blown every time I turn the lights on.

> But those details are not nearly as controversial as JFK vs. IKEv2 vs. 
> SIGMA vs. XKASS, and not even as controversial as the requirements on 
> which we'll base that choice.  This is, I think, obvious to everyone.  
> Why are you beating on this point?  Is there anyone here, with the 
> possible exception of you, who thinks that this is the crucial criterion
> on which the WG is going to decide among the different proposals?

I'm beating the point because people don't seem to understand what I'm
trying to say. That is the only conclusion I can draw when Phillip 
responds to a post in which I acknowledge the well known fact that
multiple keys can be derived from an authenticated Diffie-Hellman
secret (although that was not the point of my post) by stating that it's
possible to derive multiple keys from an authenticated Diffie-Hellman
secret. Since he obviously missed the point I felt compelled to
repeat it.

Now I'm sorry for screaming but I MADE A MISTAKE! I mistook what you
meant with what you wrote (apparently so did Markku Savela).

> To my mind, the next interesting issue is what the SA description 
> should look like.  I've heard many complaints that the current standard 
> is a significant source of complexity and interoperability problems.  
> In fact, I'd planned on writing a draft on that issue, but a number of 
> things (including the events of September 11) interfered.

Complex yes. Interoperability problems? Not for the past few years. The
interoperability problems today are not with SA construction or parsing.

> (Inflammatory comments deleted.)

Well that's nice, thanks.

  Dan.
Follow-Ups: References: