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

["Joel N. Weber II" <ietf-secsh%joelweber.com@localhost>]

> > 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.

True.

The case I was thinking of, though, is the case where the client
decides it doesn't trust the certificate presented by the server, and
that it wants to try another method.  For example, a common problem is
that your average web browser doesn't recognize the X.509 CA that
issues certificates for most HTTPS web servers in the mit.edu domain.
And with OpenPGP, everyone has their own set of trust values, and
there's no chance you could ever predict whether a client will trust a
host key without feeding the client the host key and asking whether it
trusts it.

Since the host key is sent in the last message of the public key key
exchange algorithms, the client doesn't realize that it doesn't trust
the key until key exchange would appear to have finished judging from
the messages being passed back and forth.

> > 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.

You're right; it makes perfect sense, but I hadn't realized that.

(Tangentially, if an attacker can intercept the messages between your
application server and your Kerberos KDC, there is probably a
downgrade attack there, unless your GSSAPI implementation is really
clever.  We may want to say that a GSSAPI implementation MUST abort if
an error happens which indicates that communication with the KDC
failed.  Except that, like, KDC isn't a GSSAPI term.)

> 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.

Every kex method, I believe, has a V_C and a V_S input for data that
needs to be in the hash that came before the key exchange algorithm
started running.  I think all we have to do is define that for the
first attempt at initial keyex, and for any rekeying (yes, ugh about
the ``for any rekeying, but that's where we are now), they are what
they are now, and for attempts at initial keyex after the first, V_C
and V_S somehow end up being a hash of initial V_C and V_S plus the
previous attempts at keyex.