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

[Simon Tatham <anakin%pobox.com@localhost>]

Damien Miller  <djm%mindrot.org@localhost> wrote:
>    The "zlib%openssh.com@localhost" method operates identically to the "zlib"
>    method described in [RFC4252] except that packet compression does not
>    start until the server sends a SSH_MSG_USERAUTH_SUCCESS packet,
>    replacing the "zlib" method's start of compression when the server
>    sends SSH_MSG_NEWKEYS.
> 
>    Specifically, this means that a server selecting this method MUST
>    compress the first packet after SSH_MSG_USERAUTH_SUCCESS and all
>    subsequent packets.  The client MUST compress all packets it sends
>    after the time that it receives SSH_MSG_USERAUTH_SUCCESS.

(I've already said this to Damien, but I'll say it here as well now
this is published.)

I believe this specification includes an inherent race condition,
causing the server to be unable to unambiguously determine whether a
given packet from the client is compressed or not.

The last userauth-layer packet sent by the client (say,
SSH_MSG_USERAUTH_REQUEST) is clearly uncompressed, because the
server hasn't sent SSH_MSG_USERAUTH_SUCCESS in response to it yet.
And the first connection-layer packet is clearly compressed, because
the client wouldn't have sent it except in response _to_
SSH_MSG_USERAUTH_SUCCESS. But what about transport-layer packets in
between?

If the client sends SSH_MSG_IGNORE, or initiates a rekey, in between
the last userauth-layer packet and the first connection-layer
packet, then the server might easily be unable to tell whether that
client packet was sent before or after the client received
SSH_MSG_USERAUTH_SUCCESS. The packet contains no flag to indicate
whether it's compressed; you can't go by the packet type code
because that's part of the potentially compressed payload; as far as
I can see there is no reliable way to resolve this race condition.

There should be a packet sent from the client which explicitly
indicates that subsequent packets will be compressed, as there is in
the normal KEX procedure (SSH_MSG_NEWKEYS is sent in _both_
directions). The server-to-client side is unambiguous, of course,
because SSH_MSG_USERAUTH_SUCCESS itself doubles as that packet.

As far as I can see, the only _safe_ way for a client to implement
this compression method as currently specified is to note it being
offered in the initial kex, but not to accept that offer, and then
to initiate a rekey after authentication in which we enable it.
-- 
Simon Tatham         These are my opinions. There are many
<anakin%pobox.com@localhost>   like them but these ones are mine.