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

[Alexey Ermishkin]

So, as an intermediate summary I can see that

1) We'll use strings with 1 byte length instead of versions. It allows us to specify cipher suites, patterns and whatever else.
2) Maximum packet size should be configurable. Via n1 or other mechanisms

What will be a prologue then? A concatenation of all "message type" strings from the first message? 

-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Sunday, February 05, 2017 12:50 PM
To: Rhys Weatherley <rhys.weatherley at gmail.com>
Cc: Alexey Ermishkin <scratch.net at gmail.com>; David Wong <davidwong.crypto at gmail.com>; noise <noise at moderncrypto.org>
Subject: Re: [noise] A simple and safe TLS/TCP-like protocol

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