Feedback on draft-ssh-ext-info-00

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

Hi,

Here's some feedback on draft-ssh-ext-info-00.

> 3.1.  Signaling of Extension Negotiation in KEXINIT
...
> The indicator name is added without quotes, and MAY be added at any
> position in the name-list, subject to proper separation from other
> names as per name-list conventions. The suggested position is last in
> the list, but implementations MUST recognize these indicator names
> when included at any position.

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?

> 3.2.  Mechanism Enabling Criteria

This whole section seems over-complicated. I think a simpler scheme
is:

If a client or server offers "ext-info-c" or "ext-info-s" respectively,
then it must be prepared to accept a SSH_MSG_EXT_INFO message from the
peer. 

If this message is sent, then it will be the first message after the
initial SSH_MSG_NEWKEYS.

I.e. make it a simple advertisment that a client or server is willing
to accept a notification message that might optionally be sent.
Don't require both sides to offer acceptance, don't have the messages
offer any sort of negotiation between the client and server (just
statements of extensions/capabilities) and don't "replace" any
messages like SSH_MSG_SERVICE_REQUEST.

This would yield a much simpler specification IMO.

> 4. Initially Defined Extensions
> 4.2.  "client-req-ok"

I don't see the point of this: implementations that don't respond with
SSH_MSG_REQUEST_FAILURE to unknown SSH_MSG_GLOBAL_REQUEST messages are
incompliant with RFC4254 section 4.

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.

> 4.3.  "no-handbrake"

This could be implemented more elegantly using new channel type names
in SSH_MSG_CHANNEL_OPEN messages rather than the complicated and
inflexible method proposed here (e.g. it's impossible to have one
channel without the "handbrake" and one with normal flow control).

It would be better to use the extension to signal that the
peer is willing to accept SSH_MSG_CHANNEL_OPEN messages with new channel
type names, and use these to selectively disable flow control.

Given this, IMO this would be better off being replaced by a generic
"these are the channel types I'm prepared to open" message, which would
be useful even for implementation that don't want to turn off flow control
but which do implement non-standard channel types (e.g. tun%openssh.com@localhost).

-d