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

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

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

To extend other aspects of SSH that EXT_INFO cannot. This could be to change some aspect of algorithm negotiation, for example.

For instance, there has been a problem in how AEAD is negotiated. Besides what OpenSSH did - implementing a private algorithm for AES-GCM - another possible solution could be an extension where both client and server put something in their key exchange algorithms field. If both client and server do this, then the result of MAC negotiation is ignored if an AEAD encryption algorithm is negotiated.

But why do you even feel the need to call this out? Is it any harder to call:

    is_in_namelist(name, namelist)

instead of:

    is_at_end_of_namelist(name, namelist)

?

You are saying, "I can't envision a
 usage scenario for this, so let's prevent it." This is pompous, because you implicitly consider yourself capable of predicting such scenarios. Further, you are doing this for zero benefit; as a matter of principle; and just after we've been through conversations where 
I've pointed out that we cannot predict future needs, and that this attitude - "prohibit it because we can" - has already created problems.


> IIRC I've heard of at least one server that doesn't
> implement ssh-userauth.

This is possible with EXT_INFO also. Send an extension name and value informing the client of what you implement. No need to waste a round-trip for 99.999% of other users.


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

Just simplicity, for implementations that want it.

A user mode app doesn't necessarily have info about what goes on at the TCP level, and if it does, it's something a single-channel implementation doesn't want to have to bother with.

denis


----- Original Message -----
From: Damien Miller 
Sent: Wednesday, December 2, 2015 21:10
To: denis bider 
Cc: Markus Friedl ; ietf-ssh%netbsd.org@localhost 
Subject: Re: Feedback on draft-ssh-ext-info-00

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