<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 5, 2017 at 2:53 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 
* The parties negotiate a single max_transport_size, instead of<br>
separate sizes for their receive buffers.  Separate sizes are<br>
reasonable, since it's possible to do streaming encryption and<br>
calculate the authentication tag, but it's not possible to do<br>
streaming decryption (since it's not safe to stream decrypted<br>
plaintext that hasn't been authenticated).  However, maybe it's<br>
simpler just to negotiate a single value here, instead of having<br>
separate send / receive values?<br></blockquote><div><br></div><div>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).<br><br></div><div>In the first message:<br><br></div><div>negotiation_data:<br></div><div>{<br></div><div>  "max_receive_size": 2048,<br></div><div>  "max_send_size": 256<br></div>}<br><div><br></div><div>In the response from a memory-rich peer:<br><br>{<br></div><div>   "max_send_size": 4096,<br></div><div>   "max_receive_size": 4096<br></div><div>}<br><br></div><div>In the response from a memory-poor peer:<br><br>{<br></div><div>  "max_send_size": 256,<br></div><div>  "max_receive_size": 64<br></div><div>}<br><br></div><div>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?<br><br></div><div>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().<br></div><div><br></div><div></div><div></div>Cheers,<br></div><br></div><div class="gmail_extra">Rhys.<br></div></div>