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

[Damien Miller <djm%mindrot.org@localhost>]

On Thu, 16 Apr 2009, der Mouse wrote:

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

Yes, the timing of the first compressed packet is strictly indeterminate
from the view of the server. The PuTTY people mentioned this some time
back and suggested an extension mechanism to signal "the next packet
is the first compressed one" (among other things), but the discussion
fizzled.

-d