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

[Trevor Perrin]

On Sat, Feb 4, 2017 at 4:33 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> 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 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

OK.  I guess fragmenting ciphertext based on the TCP receive window
isn't a good idea either?


>>  * 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.

True, though the throughput difference is so small it might not matter.

E.g. consider the efficiency loss with one auth tag per 64K fragment
versus 4K fragment:
 - 64K = 99.98% efficiency
 - 4K  = 99.61%

This is like a 5-minute download taking an extra second.  So if an IoT
profile mandated a 4KB maximum size it might never be an issue?


>>  * 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.
[...]
> 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.

I agree that for transport messages NoiseSocket should provide
streams, Noise message boundaries shouldn't have meaning.


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


I like that, it's like a TCP socket option.  Seems like this gives
sufficient flexibility while keeping the core protocol simple (no
negotiation).

Trevor