Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it)

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Jul 09, 2003 at 06:41:43PM -0400, Joel N. Weber II wrote:
> So, thinking a bit more about what I said yesterday, I think if we
> want to support multiple attempts at key exchange, the correct
> sematics are:
> 
> If you fail trying to do GSSAPI key exchange, use the messages already
> defined for GSSAPI key exchange error reporting, but don't disconnect.
> 
> If you send the last message in a key exchange sequence, wait to see
> if SSH_MSG_NEWKEYS comes.  If it does, your peer accepted what you
> sent in that last message, and you can send SSH_MSG_NEWKEYS too.
> (This avoids having only one side use keys from a key exchange: you
> get either both or neither, which simplifies the session identifier
> question a bit.)

If the client got an error from the peer then it knows that the
SSH_MSG_NEWKEYS won't come and so it can just try again immediately.

> If you need to try again, just send SSH_MSG_KEXINIT again.
> 
> I'm willing to write up an internet-draft along these lines after IETF
> if people think it's a good idea.

There's a problem though, and I'm not sure how it could be surmounted:

The session ID needs to be derived from all messages involved in the key
exchange, even for the failed exechanges so as to avoid downgrade
attacks.

But the session ID computation is kex-type specific so you'd have to
modify the formula for the session ID for each of the three(?) existing
kex methods.  This is most unfortunate.

Perhaps the session ID computation should be respecified to be as
follows:

H = hash(V_C || V_S || KEX_C1 || KEX_S1 || KEX_C2 || KEX_S2 || ...  ||
         KEX_Cn || KEX_Sn || <kex-method specific stuff>)

where KEX_Cx and KEX_Sx are the key exchange messages sent by the client
and server, respectively and where <kex-method specific stuff> is the
(K_S || e || f || K) part of the existing kexes.

Cheers,

Nico
--