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

[denis bider <ietf-ssh3%denisbider.com@localhost>]

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 <djm%mindrot.org@localhost> , 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