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

On Thu, 3 Dec 2015, denis bider wrote:

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

I'm suggesting you specify what is sent, not how implementations test
for it. The benefit is that ~ a paragraph of fairly useless verbiage
in your spec disappears.

> > 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'll repeat my opinion: an extension mechanism is not the place to
fundamentally retcon parts of the protocol. It breaks orthagonality
and turns implementations into spaghetti.

Perhaps you want a "no-service-requests" extension instead?

-d