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

Okay, I'll modify the draft to this effect. This may take me a bit, I currently have a few urgent things to attend to.

I would appreciate your thoughts on the question of EXT_INFO windows for client and server.

Do you find it acceptable if the proposal requires both client and server to send their first EXT_INFO immediately after NEWKEYS?

Specifically, that the server does not wait between EXT_INFO and NEWKEYS to receive anything more from the client?

That way:
- I can then put in an extension like "assume-service";
- the client can send EXT_INFO("assume-service") + SERVICE_REQUEST;
- when the client sees the server's EXT_INFO("assume-service"), it can just continue with USERAUTH_REQUEST, and SERVICE_ACCEPT is not sent.




Damien Miller <[email protected]> , 12/3/2015 7:14 AM:
On Thu, 3 Dec 2015, denis bider wrote: 
 
> > 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? 
 
At the risk of repeating myself, I think providing a simple transport 
layer extension mechanism is a fantastic idea, but don't agree that 
it should make other protocol changes (except, perhaps as extensions 
defined in the same document). 
 
-d