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

[denis bider <[e-mail]>]

If after considering this, you still really want the SERVICE_REQUEST + ACCEPT round-trip, then okay. I can change the spec to not alter this part, if this way we have something we can all agree on.

But if we change it this way, when do you want EXT_INFO to be sent? What is the window in which it should be accepted?

The current proposal makes the window:

- between NEWKEYS and SERVICE_REQUEST for the client, sent one time 

- between NEWKEYS and USERAUTH_SUCCESS for the server, sent any number of times (mainly so the server can send a second EXT_INFO just before USERAUTH_REQUEST. This way you can advertise extensions that alter user auth; but you can also have privacy for extensions that only take effect after.

If we change EXT_INFO the way you propose, and keep SERVICE_REQUEST + ACCEPT as-is - are you okay with these windows?


denis bider <[e-mail]> , 12/3/2015 6:38 AM:
> 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 <[e-mail]> , 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