Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

[nisse%lysator.liu.se@localhost (Niels Möller)]

denis bider <ietf-ssh3%denisbider.com@localhost> writes:

> I have looked at alternatives, but:
> - libssh handles the KEXINIT reserved field incorrectly (ignores
> actual value, so key exchange fails if it's not zero)

Is this a bug or not? The reserved field is intended for extensions, but
from a quick look I can't see that the spec (RFC 4253) defines any valid
behaviour when a client or server receives a non-zero value there. I
think a complient implementation ought to disconnect.

It would make some sense to combine client's and server's value in some
way, e.g., bitwise and, or taking the maximum value, and use the result
to enable extensions. But we really have to define that mechanism first,
before we can define extensions using it... So in the short term, this
field seems pretty useless.
 
> client-req-ok: Allows clients to affirm that the server can send a
> global request (especially an unrecognized global request) without
> risking the client disconnecting. This should be supported by all
> clients. It is necessary so that servers can enable active keep-alive,
> which is not otherwise possible generally because some clients do
> disconnect when they receive a global request.

This is essentially an extension saying "I don't have known bug X". I
think we should avoid those things. If we want to interoperate with
buggy implementations, I'd actually prefer hacks based on the version
strings. Sooner or later we'll see an implementation which advertises
"no bug X" but actually has bug X, and then we're back to square one.

> no-handbrake: Peter ought to like this. :) A few years late, but this
> makes window size infinite for both directions in a channel, at the
> cost of restricting the session to one simultaneous channel. This
> should help file transfer applications for which the channel flow
> control in SSH is an impediment, rather than a feature.

Makes some sense. Is the intention that the endpoints should buffer
arbitrarily large amounts of data, or is the receiver of the data stream
allowed to block and stop processing ssh messages while delivering the
data?

I think I'd prefer to do it per-channel, and if enabled, let the parties
do their best if other channels are starved for data or get blocked. And
if it is intended to be a global state, a GLOBAL_REQUEST seems more
appropriate than an extension to the *transport* layer of the ssh
protocol.

If we want to improve on the flow control in ssh-connection, it might
also make sense to look at what other recent multiplexing protocols do,
e.g, http/2.

Regards,
/Niels

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