[noise] A simple and safe TLS/TCP-like protocol
trevp at trevp.net
Sat Feb 4 23:50:15 PST 2017
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
> 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
More information about the Noise