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

[denis bider <[e-mail]>]

*blush* :)

Sounds good. Can you post a writeup of the scheme you implement?

It doesn't have to be an Internet-Draft, just something better than reverse engineering source code.

(A spec might not only make things easier for others, but also improve the implementation. I find that writing things down helps call to mind corner cases I would have ignored otherwise.)


----- Original Message -----
From: Markus Friedl 
Sent: Wednesday, December 2, 2015 08:39
To: [e-mail] 
Cc: Damien Miller 
Subject: Re: Feedback on draft-ssh-ext-info-00

I'm in the process of implementing draft-rsa-dsa-sha2-256-03 and
welcome a way for signaling SHA2 support to the client for userauth,
especially since I'm sabotaging protocol extensions with the strict
message format checks I've added to OpenSSH before.

However, I also agree with Damien that the suggested proposal seems
unnecessary complex to me and will try to implement the simpler
scheme he suggests.

-m



> Am 02.12.2015 um 12:35 schrieb Damien Miller <[e-mail]>:
> 
> 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. [e-mail]).
> 
> -d
>