Bug report: first_kex_packet_follows behaviour seems wrong

[Richard Peters]

Hello,

It seems to me the algorithm negotiation of the transport layer has a bug,
it does not follow the specification of draft-ietf-secsh-transport-24, page
19, where the behaviour of first_kex_packet_follows is specified.

I've got an ssh client that sends an SSH_MSG_KEXINIT message and specifies
only 'diffie-hellman-group1-sha1' as key exchange algorithm. It sets
first_kex_packet_follows to true, and immediately sends the
SSH_MSG_KEXDH_INIT message. The ssh server (openssh-3.9p1) specifies three
key exchange algorithms in its SSH_MSG_KEXINIT message:
'diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellm
an-group1-sha1'. This results in diffie-hellman-group1-sha1 being the
algorithm used. So, I would think my client's guess is right, and its next
message is not ignored by the server. However, the ssh server gives me the
following debug output:

    debug2: proposal mismatch: my diffie-hellman-group-exchange-sha1 peer
diffie-hellman-group1-sha1
    debug2: skipping next packet (type 30)

The server indeed put its diffie-hellman-group-exchange-sha1 first in its
list, but that does not mean my client's guess was wrong. My client guessed
that diffie-hellman-group1-sha1 would be the algorithm chosen, and
anticipated by sending a SSH_MSG_KEXINIT message. That guess was right, so
its next message should not be ignored.

I'll include the description of the 'first_kex_packet_follows' field as
specified in draft-ietf-secsh-transport-24:

      first_kex_packet_follows
         Indicates whether a guessed key exchange packet follows.  If a
         guessed packet will be sent, this MUST be TRUE.  If no guessed
         packet will be sent, this MUST be FALSE.

         After receiving the SSH_MSG_KEXINIT packet from the other side,
         each party will know whether their guess was right.  If the
         other party's guess was wrong, and this field was TRUE, the
         next packet MUST be silently ignored, and both sides MUST then
         act as determined by the negotiated key exchange method.  If
         the guess was right, key exchange MUST continue using the
         guessed packet.

The server should not look at its own list of key exchange algorithms when
determining whether to ignore my client's next message, but it should
compare the chosen algorithm to the first algorithm specified in my client's
list. If those two do not match, then the client's guess was wrong,
otherwise, the server should not ignore my client's SSH_MSG_KEXDH_INIT
message.

best regards,

Richard Peters