Re: applying AES-GCM to secure shell: proposed "tweak"

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Avoiding the attack surface presented by compression libraries
>> before authentication of the user.

That strikes me as a desirable end.

But the I-D I saw named upthread doesn't look like a good way to do it.
When the server starts compressing is well-defined, but the point in
the client->server data stream at which the client starts compressing
is, from the point of view of the server, ill-defined; the only way I
see to make it well-defined as the algorithm is defined is for the
client to never send anything, even IGNORE or other such messages,
between the time it sends a packet which could provoke a
USERAUTH_SUCCESS response and the time it receives some kind of
response to it.  However, the spec does not specify anything of the
sort - leaving, I believe, this ill-defined.

> Hmm, why not just apply it only to the data packets?

That makes sense to me (and seems well-defined, at least once you
specify precisely what "data packets" are, presumably
SSH_MSG_CHANNEL_DATA, maybe SSH_MSG_CHANNEL_EXTENDED_DATA, possibly a
few others such as SSH_MSG_CHANNEL_WINDOW_ADJUST).  I may try
implementing it.

> The random non-data-related messages exchanged (again, mostly
> high-entropy binary blobs) aren't going to compress much (if at all),

I disagree.  There are a lot of non-data messages that are full of
uint32 fields that typically have at least 3/4 of their bits zero.
Some even use a 32-bit field to carry one bit of information.
Compressing these is valuable from the point of view of providing
higher-entropy data as the cleartext to the encryption algorithm and
therefore making it harder to attack.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B