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

[denis bider <ietf-ssh3%denisbider.com@localhost>]

> 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 ; ietf-ssh%netbsd.org@localhost 
Subject: Re: Feedback on draft-ssh-ext-info-00

> On Fri 11/12/2015, at 4:39 pm, Niels Möller <nisse%lysator.liu.se@localhost> 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 "kexguess2%matt.ucc.asn.au@localhost" 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