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

[Damien Miller <djm%mindrot.org@localhost>]

On Thu, 3 Dec 2015, denis bider wrote:

> > IMO it would be best to make it a MUST that the flags
> > may only be sent as the last element. What rationale is
> > there for putting it anywhere else?
> 
> In the event that there are two or more competing extension mechanisms, only
> one of them can be last.

If there's a functioning extension mechanism, then why would there be
competition?

Even if there were, then it's up to whoever writes the second one to
deal with making their fit.

> > and don't "replace" any messages like
> > SSH_MSG_SERVICE_REQUEST.
> 
> But but but I waaaant to replace this awful SSH_MSG_SERVICE_REQUEST. :)
> 
> Does no one agree that SERVICE_REQUEST + ACCEPT are pointless?
> 
> A whole round-trip delay? For no benefit - in any known usage scenario?

IMO replacing messages in the protocol is something best saved for
SSH-3.x. IIRC I've heard of at least one server that doesn't implement
ssh-userauth.

> > OpenSSH has sent various @openssh.com global
> > requests for years, so most of the implementations
> > that violate this should have long since been shaken out.
> 
> Do you happen to know:
> 
> - Since which version the OpenSSH server has been sending global requests?

3.8ish, released early 2004

> - Since which version the OpenSSH client has been tolerating them?

at least that long :)

> There are still folks out there using OpenSSH 3.x and 4.x. I'm pretty sure I
> saw our software being connected to by a client like that in the past week.

4.x should be fine, older 3.x might have problems - I haven't checked.

Honestly though, anyone using OpenSSH 3.x has bigger problems than
channel requests upsetting their connections.

> > (e.g. it's impossible to have one channel without the
> > "handbrake" and one with normal flow control)
> 
> As discussed, this is on purpose. If you want multiplexing, implement
> multiplexing, including flow control.
> 
> If even one channel does not have flow control, this affects the transport
> layer also. It affects keep-alive mechanisms, key exchange, and flow control
> at the transport level.

Right, "no-handbrake" breaks all of these. I'm not sure what the gain is
either compared to making the SSH window match the TCP window size. It's
not like SSH can go send more data than that.

-d