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

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

On Mon, 20 Nov 2006, Nicolas Williams wrote:

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

Which is why I suggested a "client authentication complete" and not a
"I'm starting compression" message. The message will only have meaning
to a server that is using a delayed compression method, and the server
can respond appropriately if it is sent at an inappropriate time, such
as before it has sent a SSH_MSG_USERAUTH_SUCCESS.

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

Well, the only things that can be safely renegotiated in KEX are 
compression and languages - I don't think it would be safe to 
renegotiate MACs/ciphers whilst retaining the same keys. I don't see
much practicality in renegotiating languages, so you would effectively 
be defining a whole new KEX exchange just to negotiate the compression
method.

-d