Subject: key re-exchange with compression enabled

From: "Joseph Galbraith" <[email-masked]>
Date: Tue, 3 Oct 2000 14:08:54 -0600

I believe draft-ietf-secsh-transport-07 is
ambiguous with regards to how the hash H is
computed during key re-exchange when compression
is on.

Here is a quote from Section 6 (pg, 14):

  The hash H is computed as the HASH hash of the
  concatenation of the following:

    string    V_C, the client's version string (CR and NL excluded)
    string    V_S, the server's version string (CR and NL excluded)
    string    I_C, the payload of the client's SSH_MSG_KEXINIT
    string    I_S, the payload of the server's SSH_MSG_KEXINIT
    string    K_S, the host key
    mpint     e, exchange value sent by the client
    mpint     f, exchange value sent by the server
    mpint     K, the shared secret

In the case of the initial key exchange, compression
is always off, and there is no confusion.

However, if a key re-exchange is in progress and
compression was negotiated by the prior key exchange,
then the current wording would seem to imply that the
compressed payload should be used in the hash.

It appears that current implementations (or at least SSH
Communications 2.3.0) use the uncompressed packet payload.

I believe I_C and I_S should be clarified to read
as follows:

  string    I_C, the uncompressed payload of the client's SSH_MSG_KEXINIT
  string    I_S, the uncompressed payload of the server's SSH_MSG_KEXINIT

Thanks,

Joseph Galbraith
[email-masked]

---

From: [email-masked] (Niels M�ller)
Date: 04 Oct 2000 00:13:52 +0200

> Communications 2.3.0) use the uncompressed packet payload.

That's the natural way to do it, I guess. I deal with both decrypting
and inflating of incoming packets before I look inside them. The
encrypted and compressed data is thrown away before I even look at the
message type and contents. Similarly on the way out, I generate
cleartext uncompressed packets and put them on the transmission queue.
The code that compresses the packets doesn't care about the message
type or contents, and compressed data is thrown away as soon as it is
encrypted or passed to write() by the next handler on the queue.

>   string    I_S, the uncompressed payload of the server's SSH_MSG_KEXINIT

If the processing described above is not obvious, the spec could need
some clarification. But instead of clarifying every use of the word
"payload", I think it would be a good idea to use the word "payload"
_exclusively_ for the cleartext uncompressed packets, and some other
word when talking about possibly encrypted and/or compressed data that
appears closer to the wire. E.g. replace

: Each packet is of the following format.
: 
:   uint32    packet_length
:   byte      padding_length
:   byte[n1]  payload; n1 = packet_length - padding_length - 1
:   byte[n2]  random padding; n2 = padding_length
:   byte[m]   mac (message authentication code); m = mac_length
:
: [...] 
:
:     payload
: 	The useful contents of the packet.  If compression has been
: 	negotiated, this field is compressed.  Initially, compression MUST
: 	be "none".

with

: Each packet is of the following format.
: 
:   uint32    packet_length
:   byte      padding_length
:   byte[n1]  contents; n1 = packet_length - padding_length - 1
:   byte[n2]  random padding; n2 = padding_length
:   byte[m]   mac (message authentication code); m = mac_length
:
: [...]
:
:     contents
: 	The useful contents of the packet. If compression has been
: 	negotiated, decompression of the contents yields the
: 	packet payload; otherwise, the payload and the contents are the
: 	same. Initially, compression MUST
: 	be "none".

Regards,
/Niels