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

> Why add fixed-function fields to a generic extension mechanism? 

So as to avoid ret-conning functionality provided by SERVICE_REQUEST + ACCEPT.

These two messages always negotiate the service (e.g. "ssh-userauth"). So EXT_INFO, which is a replacement, also always negotiates the service.

This is in fact simpler than adding a "services" extension, and then mandating that this extension "MUST" be handled by all implementations. If some functionality must always be handled, a fixed field is appropriate.


> Merely advertising a willingness to accept SSH_MSG_EXT_INFO
> shouldn't have other further effects on the protocol. To do
> otherwise is IMO quite surprising. 
 
Okay, imagine this:

(1) Instead of the EXT_INFO message, we continue to send SERVICE_REQUEST + ACCEPT.

(2) The KEXINIT extension instead signals that extension fields can be added to SERVICE_REQUEST + ACCEPT.

(3) Presence of the KEXINIT extension further signals that the server can send a presumed SERVICE_ACCEPT, without waiting for SERVICE_REQUEST.

Do you see that this results in the same proposal, just with renamed messages?



Damien Miller <[email protected]> , 12/3/2015 6:31 AM:
On Thu, 3 Dec 2015, denis bider wrote: 
 
> 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? 
 
This is over-complicated. Why add fixed-function fields to a generic 
extension mechanism? 
 
I'd support a simple magic name, offered in KEXINIT to indicate that an 
implementation is prepared to accept a SSH_MSG_EXT_INFO packet. 
Merely advertising a willingness to accept SSH_MSG_EXT_INFO shouldn't 
have other further effects on the protocol. To do otherwise is IMO quite 
surprising. 
 
Then, if you want to define a "die-service-request-die" extension that 
changes the protocol flow then you can do that without requiring other 
implementations to follow suit. 
 
-d