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

[Alexey Ermishkin]

I think we can try strings with 1 byte prepending length and see how it goes.

 

As for chopping data, in my POC

https://github.com/go-noisetls/noisetls/blob/master/conn.go#L170

I used the same approach TLS uses. If I need to send N bytes, I ask my code how much can I send right now and split data into chunks. Each chunk is an encrypted noise transport message, so it’s implicitly authenticated with AEAD and has length field 2 bytes which cannot exceed 64k. So, high-level code treats everything like a stream, but each chunk is authenticated separately and you don’t need to extra MAC plaintext

 

 

 

From: Noise [mailto:noise-bounces at moderncrypto.org] On Behalf Of Rhys Weatherley
Sent: Saturday, February 04, 2017 4:53 AM
To: David Wong <davidwong.crypto at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] A simple and safe TLS/TCP-like protocol

 

On Sat, Feb 4, 2017 at 8:33 AM, David Wong <davidwong.crypto at gmail.com <mailto:davidwong.crypto at gmail.com> > wrote:

> From the IETF/TLS experience, I'm pretty opposed to global number registries. It adds a lot of friction when everyone has to negotiate with authorities to get their numbers assigned

 

this ^

 

This would hurt the simplicity of Noise so much. Strings are fine, and they make reading the code easily.

 

I'm "Team String" as well  As Trevor points out, it is much easier for experimenters to pick a name and get going without waiting for the rubber stamp first. 

 

Strings do have one drawback though - they are arbitrary-length which can be an issue for IoT devices.  This is also an issue for message payloads after the handshake completes.

I regularly work on embedded chips with RAM sizes of 8K, 20K, 48K, etc.  The maximum Noise packet payload is 65535 bytes.  When the IoT device is sending, this isn't an issue because it can pick a maximum size that is convenient for the device's RAM constraints.

On the receiving side it is a big issue if the sender can choose whatever length it likes.  Particularly for message payloads: the MAC must be checked before the data is used but the MAC may not arrive within the memory constraints of the receiver.

On a previous project I was trying to implement SSH for Arduino devices, which requires support for a minimum packet size of 35000 bytes.  The best I could do was implement a streaming mechanism to decrypt the packet on the fly, consume the plaintext, and check the MAC later.  It is of course really dumb to use data which hasn't been authenticated yet, which is why I stopped work on SSH.  It just can't work in a RAM-constrained environment.

Long story short: we should probably define a maximum protocol name size (128? 256? something like that), and provide some mechanism in the TLS replacement to negotiate a maximum message payload size so that IoT receivers can force the other end to chop the session data up into smaller pieces.  If the sender exceeds the negotiated maximum, the receiver aborts the connection.

 

Cheers,

Rhys.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170204/8ebe80f4/attachment.html>