first_kex_packet_follows improvement

I'm working on improving my ssh client's connection setup
time, round trips etc.  The current behaviour of
first_kex_packet_follows isn't useful where implementations
have differing sets of kex or host key methods. I'm
proposing a small modification allowing
first_kex_packet_follows to be used between any
implementations. 

Currently for first_kex_packet_follows to be utilised the first
listed algorithm must be the same on both sides. For example
OpenSSH specifies [email protected] as its first
host key algorithm - first_kex_packet_follows can't work
unless the other side also implements that. I've found a
couple of old list mails that are relevant [1][2].


Section 7 of rfc4253 has:

"""The guess is considered wrong if:
o the kex algorithm and/or the host key algorithm is guessed wrong
(server and client have different preferred algorithm), 
or ..."""

The modified behaviour would be:

"""The guess is considered wrong if:
o the preferred (first listed) kex algorithm and/or the
preferred host key algorithm of a side indicating
first_kex_packet_follows does not match the algorithm
negotiated as in Section 7.1,
or ..."""

Implementations indicate their use of the new behaviour by
adding "[email protected]" to the kex algorithm list
after all usable kex algorithms. The modified
first_kex_packet_follows behaviour MUST be used if both
sides list that algorithm, otherwise the existing RFC4253
behaviour MUST be used. If the [email protected]
algorithm is negotiated as per section 7.1 both sides MUST
exit. ["kexguess2" would be the name if standardised]


Thoughts and comments? The kexguess2 flag is a bit ugly but
is relatively unobtrusive, I can't see a better way.

Cheers,
Matt
Dropbear SSH developer


[1] http://lists.mindrot.org/pipermail/openssh-unix-dev/2005-June/023039.html
[2] http://thread.gmane.org/gmane.ietf.secsh/2707/focus=2754