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

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Damien Miller wrote:
> Hi,
> 
> Please publish the attached I-D: draft-openssh-secsh-compression-delayed-00.txt

Thanks for publishing this; just FYI: I believe we have
an inter-operable implementation of this.

>    The "zlib" compression in method defined in [RFC4253] for the SSH
>    protocol uses ZLIB (LZ77) compression (as described in [RFC1950] and
>    [RFC1951]).  This method activates compression after the completion
>    of the key exchange algorithm, upon the receipt of the
>    SSH_MSG_NEWKEYS message.  This step occurs before user authentication
>    [RFC4252] completes, so a bug in the underlying compression code
>    could be exposed to unauthenticated users.
> 
>    This new compression method "zlib%openssh.com@localhost" addresses this risk by
>    delaying the start of compression until the completion of the user
>    authentication exchange.

An additional benefit of this is that it prevents sensitive
information such as the username and password from becoming
part of the internal zlib state where it is hard to scrub
it from memory.

> 3.  Delayed Compression
> 
>    The "zlib%openssh.com@localhost" method operates identically to the "zlib"
>    method described in [RFC4252] except that packet compression does not

I believe you probably meant to reference RFC4253 (transport)
here?

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

Isn't this problematic on the client side?  The server doesn't
know when the client will receive the SSH_MSG_USERAUTH_SUCCESS.

In fact, I RFC4352 allows the client to send multiple
auth requests with out waiting for a response.  The server
is suppose to ignore any auth requests after success:

>    The client MAY send several authentication requests without waiting
>    for responses from previous requests.  The server MUST process each
>    request completely and acknowledge any failed requests with a
>    SSH_MSG_USERAUTH_FAILURE message before processing the next request.
> 
>    A request that requires further messages to be exchanged will be
>    aborted by a subsequent request.  A client MUST NOT send a subsequent
>    request if it has not received a response from the server for a
>    previous request.  A SSH_MSG_USERAUTH_FAILURE message MUST NOT be
>    sent for an aborted method.
> 
>    SSH_MSG_USERAUTH_SUCCESS MUST be sent only once.  When
>    SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication
>    requests received after that SHOULD be silently ignored.

In this case (or possibly in the case of DEBUG, IGNORE, or even
a KEXINIT packet) the server might receive uncompressed packets
after it sends the SSH_MSG_USERAUTH_SUCCESS-- the server really
has no way of determining at what point the packet stream became
compressed.

Of course in most implementations, it is okay since clients tend
to send one auth method at a time and wait for the response.

Thanks,

Joseph