[noise] A simple and safe TLS/TCP-like protocol

[Rhys Weatherley]

On Sun, Feb 5, 2017 at 5:57 AM, Trevor Perrin <trevp at trevp.net> wrote:

>  * Is fragmenting ciphertexts actually sufficient for small-memory
> devices?  Isn't it still a problem if the device is receiving and
> buffering an excessive *volume* of ciphertext, regardless of how it's
> fragmented?  I.e., if there needs to be message size/volume limits in
> general, wouldn't that solve this problem more thoroughly than
> fragmentation?
>

I see that as a network-layer flow control problem, which TCP already has
mechanisms for.  I've never been a fan of the window flow control
mechanisms in TLS and SSH - it's usurping functions already provided by TCP
(to be fair, the multiple channels in SSH do require per-channel flow
control to avoid starvation).

In Arduino it is common for the TCP/IP layer to be provided by a separate
co-processor (Wiznet W5100 and W5500 chipsets are common).  Network
buffering and flow control is done in this separate co-processor and
doesn't eat into the memory of the main CPU where Noise would be running.
The main CPU executes recv()/send() calls which thunk over to the
co-processor to service one packet at a time.

 * In typical IoT cases, can't both sides just be configured to send
> small messages, or fragment at some hard-coded limit?  Does this need
> to be *negotiated*?
>

If it is just IoT devices "phoning home", the application can arrange ahead
of time to limit things.  But there will be other devices in the network;
e.g. an administrator on a laptop connecting into the IoT server to perform
maintenance.  And over time, IoT devices become more capable - if the
application limits to the lowest common denominator then throughput is
always limited to that of years-old equipment.


>  * If negotiation is needed, can't this be left to the application?
> I.e., if we allow applications to choose the handshake message
> payloads to send certificates etc, they can add their own negotiation.
> Then we don't have to burden all NoiseSocket implementations with an
> infrequently-needed feature.
>

My preference is that NoiseSocket be a simple TCP wrapper with little
burden placed on the application to deal with flow control and fragment
sizes.  Think of how TCP handles the path MTU - it is largely invisible to
the application that messages may be chopped into smaller portions.

That is, the NoiseSocket layer is allowed to chop requests into smaller
portions.  The Noise message boundaries do not imply anything about
application-level message boundaries.

If we do leave negotiation up to the application, then I would like to see
a standardized SetMaxFragmentSize() function in the NoiseSocket API that
the application can call once it has negotiated the size by whatever means
(hard-coded limit, negotiation during handshake, negotiation after
handshake, etc).  After that, the API chops messages up itself.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170205/5d272f23/attachment.html>