Re: Feedback on draft-ssh-ext-info-00

> On Fri 11/12/2015, at 4:39 pm, Niels Möller <[email protected]> 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 protected]" 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