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

denis bider <[email protected]> writes:

> 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?

I think that's a reasonable place to send it. I view EXT_INFO as a part
of the transport layer, and then the spec ought to not depend on messages
belonging to the ssh-userauth or the ssh-connection service. 
 
But maybe I'm missing the issue... As a client, you want to know what
extensions are supported *before* you send the SERVICE_REQUEST message?
But it it's optional, you can't know if the server is not sending any
EXT_INFO, or if it's going to send it but you haven't received it yet.

Is that right?

Since the protocol is specified as running over a byte stream, we ought
not to reason in terms of the EXT_INFO arriving in the same packet as
the NEWKEYS, even if that probably would work in practice.

To remove the ambiguity, negotiation has to be a bit more complex.
We'd need four more magic symbols,

  ext_info_{send,recv}_{c,s}

and specify that the server MUST send EXT_INFO if and only if the
client advertised ext_info_recv_c and the server advertised
ext_info_send_s. 

Then the client knows unabiguously if there will be an EXT_INFO following
the NEWKEYS.

And similarly for the other direction.

Is there any simpler way to do it?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.