Subject: Post-user-auth compression as an extension? (Re: Feedback on draft-ssh-ext-info-00)

From: denis bider <[email-masked]>
Date: Mon, 14 Dec 2015 00:53:25 +0000

> Regarding the secondary SSH_MSG_EXT_INFO before
> SSH_MSG_USERAUTH_SUCCESS there's a race condition - the server
> can't tell if subsequent packets it receives were sent by the
> client prior to receiving SSH_MSG_EXT_INFO

It seems to me that resolving this race condition in a generic manner requires an acknowledgment from the client that it has received the second SSH_MSG_EXT_INFO. However, it seems weird to be defining such an acknowledgment for hypothesized extensions, without a known extension using it.

But perhaps we should define such an extension. :-)

How about defining an extension for negotiation of post-user-auth compression?

That would:

- Allow the client and server to avoid re-doing key exchange, which is currently required for safe implementation of the popular post-user-auth compression scheme.

- Allow for the server to avoid advertising it supports compression to unauthenticated clients.

- Provide a specific case to justify the client sending an acknowledgment that it has received SSH_MSG_EXT_INFO.

----- Original Message -----
From: Matt Johnston 
Sent: Friday, December 11, 2015 09:31
To: Niels Möller 
Cc: denis bider ; Damien Miller ; Markus Friedl ; [email-masked] 
Subject: Re: Feedback on draft-ssh-ext-info-00

> On Fri 11/12/2015, at 4:39 pm, Niels Möller <[email-masked]> wrote:
> ...
> Since the protocol is specified as running over a byte stream, we ought
> not to reason in terms of the EXT_INFO arriving in the same packet as
> the NEWKEYS, even if that probably would work in practice.
> 
> To remove the ambiguity, negotiation has to be a bit more complex.
> We'd need four more magic symbols,
> 
>  ext_info_{send,recv}_{c,s}
> 
> and specify that the server MUST send EXT_INFO if and only if the
> client advertised ext_info_recv_c and the server advertised
> ext_info_send_s. 

Why not keep just ext_info_{c,s} and specify that client and server both MUST send SSH_MSG_EXT_INFO immediately after SSH_NEWKEYS iff both sent ext_info_{c,s}? Then they both know what to expect.

Regarding the secondary SSH_MSG_EXT_INFO before SSH_MSG_USERAUTH_SUCCESS there's a race condition - the server can't tell if subsequent packets it receives were sent by the client prior to receiving SSH_MSG_EXT_INFO - the same as the delayed zlib race [1]. Probably won't be a problem for the current extensions but it could cause trouble if it's used for transport-level extensions.

I think "server-sig-algs" should have "auth" somewhere in the name to avoid confusion with hostkey algorithms. Not a huge deal.

As a small data point Dropbear client has been sending SERVICE_REQUEST and USERAUTH_REQUEST in the same TCP packet since 2013 (2013.57) with no reports of problems. That said Dropbear is a lot more widely used as a server than client - I'm sure there could be something that wouldn't handle it.

FWIW Dropbear is already using the kex algorithm "[email-masked]" to signal more permissive first_kex_packet_follows negotiation. [2]

Cheers,
Matt

[1] Simon's comment http://thread.gmane.org/gmane.ietf.secsh/6108/focus=6110
[2] http://www.ietf.org/mail-archive/web/secsh/current/msg00657.html

---

From: [email-masked] (Niels Möller)
Date: Tue, 15 Dec 2015 09:53:19 +0100

> How about defining an extension for negotiation of post-user-auth compression?

Maybe. But to make progress, I'd recommend focusing in getting the
extension mechanism landed first.

About the race, Simon (referred to in Matt's reply) describes the proper
solution: Define a "NEWCOMPRESS" message, sent in each direction, just
prior to the first compressed message.

> [1] Simon's comment http://thread.gmane.org/gmane.ietf.secsh/6108/focus=6110

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.