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

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

Niels:

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

This is a bug. The implementation forgets to decode this field. It does not disconnect on purpose. The disconnect is just a side effect of key exchange failing.


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

You cannot extend the protocol using this field, if existing implementations disconnect when they see a new value. That would not allow for extension. It would require replacement of the protocol with a new and incompatible version.

This goes to show that this kind of thing is not obvious to everyone, and must be explicitly spelled out. It is a flaw of RFC 4253 that it assumes people will understand how extension fields function, and does not spend a paragraph on this.


> So in the short term, this field seems pretty useless.

The common convention with extension flags is as follows. If you are unaware of any extensions:

(1) Always set the defined non-extended value. This is usually zero.
(2) DO NOT EVER VERIFY that you have received some particular value.

That's all there is to it. That's how extension fields function. An application that is aware of the extension will notice a non-zero value if it's received, and will know what to do with it.

The problem is that this extension strategy is fragile. For this to work, all implementations have to do the correct thing: which is to reliably send the non-extended value if they're unaware; and never verify the received value.


> > client-req-ok
> This is essentially an extension saying "I don't have
> known bug X".

The behavior isn't known to be a bug. It's an ambiguity in the spec, which produces this behavior when combined with implementers who think there's benefit in being difficult on purpose. (For illustration, see your reasoning with respect to KEXINIT extension field.)

This is an extension saying "I implement non-guaranteed behavior X".


> Sooner or later we'll see an implementation which advertises
> "no bug X" but actually has bug X,

There's no reason to expect that. Disconnecting on global request is not some kind of "whoops". It's a "feature" implemented by someone who likes to makes things difficult on purpose. It does not necessarily violate the spec because the spec is silent on whether clients should gracefully handle a global request.


> > no-handbrake
> 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?

The intention is that TCP-based flow control is used.


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

Enabling this by necessity changes flow control for the entire session.


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

I think our multiplexing is fine. This extension is to accommodate applications that don't want to multiplex.


denis


----- Original Message -----
From: Niels "Möller" 
Sent: Monday, November 9, 2015 13:05
To: denis bider 
Cc: ietf-ssh%netbsd.org@localhost ; Jeffrey Hutzelman ; Mark D. Baushke ; stephen.farrell%cs.tcd.ie@localhost ; jon%siliconcircus.com@localhost ; djm%mindrot.org@localhost ; Peter Gutmann ; Max Horn 
Subject: Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

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.