Re: Publish ID draft-openssh-secsh-compression-delayed-00.txt

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Tue, Nov 21, 2006 at 12:21:48PM +1100, Damien Miller wrote:
> [removing internet-drafts@ from the Cc]
> 
> On Mon, 20 Nov 2006, Bill Sommerfeld wrote:
> 
> > On Mon, 2006-11-20 at 08:15 -0700, Joseph Galbraith wrote:
> > > Isn't this problematic on the client side?  The server doesn't
> > > know when the client will receive the SSH_MSG_USERAUTH_SUCCESS.
> > 
> > Indeed.  Seems to me like you'd need a client message saying
> > "compression starts after this message" to avoid this ambiguity.
> 
> That is a good idea. As other have observed, OpenSSH doesn't suffer from
> the race because it doesn't send other packets after authentication.
> 
> So we could define a global message with no "payload":
> 
> SSH_MSG_CLIENT_AUTHDONE	62

SSH_MSG_NEW_COMPRESSION, make its payload the name of the compression
algorithm.  Or re-use KEX, see below.

> The client would send this message upon receipt of the SSH_MSG_USERAUTH_SUCCESS.

Or whenever it wants, but NOT before then (since the whole point is not
to have compression in use prior to dropping privileges needed to
perform authentication on the server side).

> If the client has selected the delayed compression mode, it will be the
> last uncompressed message it sends.

The nice thing about using a KEX for negotiating a new compression
algorithm is that both peers are in control -- the server can continue
to not offer compression until authentication is completed, for example.

With SSH_MSG_NEW_COMPRESSION the client can't know whether the server is
ready for it.  And the whole we-need-this-so-we-can-do-compression-
after-dropping-privs thing smacks me as rather implementation specific.

KEX doesn't have that problem.

What's not nice about using KEX to negotiate a new compression algorithm
is that KEX is not cheap.  If there was a no-op key exchange algorithm
for use in re-keying whose purpose was to allow re-negotiation of things
other than session keys (and could not be used for initial KEX, but
could be advertised in initial KEX) then we could just use
KEXINIT/KEX*/NEWKEYS to negotiate compression and all would be fine.

Nico
--