[noise] Negotiating transport message size (was: Re: NoiseSocket revision 1)
trevp at trevp.net
Sat Aug 5 00:43:28 PDT 2017
On Fri, Aug 4, 2017 at 9:14 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> I think having separate send / receive is useful. Consider an interactive
> SSH client. The client is sending keystrokes so it doesn't need a big
> outgoing buffer, but the incoming buffer may be larger to handle responses
> from the server. On the server side, the receive buffer is the one that is
> smaller (think an IOT device running an SSH server for remote
> In the first message:
> "max_receive_size": 2048,
> "max_send_size": 256
> In the response from a memory-rich peer:
> "max_send_size": 4096,
> "max_receive_size": 4096
> In the response from a memory-poor peer:
> "max_send_size": 256,
> "max_receive_size": 64
> Both sides will use the minimum of the respective "me: max_send_size, peer:
> max_receive_size" pairs when choosing buffer sizes for a direction.
Is there a need to transmit max_send_size?
If not, the question is whether it's worth having separate
max_receive_size for each direction, versus a single
In your case:
* The SSH-like client probably doesn't have a limit here, and can
just use the default of 65535.
* Could the memory-poor peer just use the same buffer for encrypting
and decrypting, and set max_transport_size to 320 or something?
> For handshake packets, I think we need to allow packets to be larger than
> the negotiated maximum because each handshake step has a minimum size prior
> to the payload. The negotiated maximum can limit the size of the payload in
> a handshake packet, but not the size of the mandatory Noise handshake data.
I was assuming the negotiated limit would just apply to transport
messages. At least, for the large-message case that's probably all
For the small-memory case, I think you're right the handshake messages
will have a mandatory size, so there's not much room to negotiate.
More information about the Noise