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

> I'll repeat my opinion: an extension mechanism is not
> the place to fundamentally retcon parts of the protocol.

It's not intended as a retcon. It's a negotiated replacement of an existing (inflexible, inefficient, almost pointless) mechanism with a new (flexible, efficient, worthwhile) mechanism.

Compare this to SMTP HELO replaced by EHLO. This did not require bumping the SMTP protocol version.

The change is only a retcon if it removes functionality that SERVICE_REQUEST + ACCEPT have. So basically, you're saying that while the negotiation provided by SERVICE_REQUEST is pointless in the vast majority of cases, it is being relied upon by a small percentage of implementations, and this should be respected.

If that's what you're saying, you have a point. In order to be a proper replacement, and not a retcon, it has to preserve existing functionality.

I have posted a new draft to address this:

https://tools.ietf.org/html/draft-ssh-ext-info-03

The difference is that there is now a "services" field in EXT_INFO:

    byte       SSH_MSG_EXT_INFO (value 7)
    name-list  services
    uint32     nr-extensions
    repeat "nr-extensions" times:
      string   extension-name
      string   extension-value
And a section to describe it:

3.5.  Service Negotiation  The client and server each include a name-list of supported services
  in EXT_INFO. The name-lists are matched to negotiate a service in the
  same way as name-lists are matched in KEXINIT. Clients and servers
  that support only "ssh-userauth" MUST send this service name only.
  Implementations supporting only one service MAY assume it will be
  negotiated, and MAY send messages on that premise without waiting.
Would you agree this makes EXT_INFO a proper superset of SERVICE_REQUEST + ACCEPT?


denis bider <[email protected]> , 12/3/2015 4:14 AM:
> I'm suggesting you specify what is sent, not how
> implementations test for it. 

It is important to specify what to test for. Just weeks ago, we had a conversation about how RFC 4253 should have spelled out that the "reserved" field must be sent as zero, but must not be checked that it is zero.

It is important to specify what things implementations should not check for, when incorrect implementation may cause compatibility issues.


> The benefit is that ~ a paragraph of fairly
> useless verbiage in your spec disappears. 
 
You are losing my respect as we continue.


Damien Miller <[email protected]> , 12/3/2015 4:06 AM:
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