[noise] Negotiating transport message size (was: Re: NoiseSocket revision 1)

Rhys Weatherley rhys.weatherley at gmail.com
Fri Aug 4 14:14:26 PDT 2017


On Sat, Aug 5, 2017 at 2:53 AM, Trevor Perrin <trevp at trevp.net> wrote:

>   * The parties negotiate a single max_transport_size, instead of
> separate sizes for their receive buffers.  Separate sizes are
> reasonable, since it's possible to do streaming encryption and
> calculate the authentication tag, but it's not possible to do
> streaming decryption (since it's not safe to stream decrypted
> plaintext that hasn't been authenticated).  However, maybe it's
> simpler just to negotiate a single value here, instead of having
> separate send / receive values?
>

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
administration).

In the first message:

negotiation_data:
{
  "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.  If the
resulting value is too small (e.g. the application cannot split packets
less than 64 bytes in size), then the connection aborts.  The field names
may need some work; max_init_size / max_resp_size?

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.  A memory-poor device can combine its send and receive buffers to get
extra space during the handshake, and then switch to separate limits after
the Split().

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170805/7811a5d1/attachment.html>


More information about the Noise mailing list