[noise] Padding & sending data during the handshake

[Alexey Ermishkin]

TLS is an abbreviation, but yes, it's a subject to discuss. My thought was that Noise Socket is a protocol and everything else is its implementations.
I've regged go-noisesocket just in case :)

As for the padding, "app level"  padding will overlap but have almost zero influence on the packet padding, only the total traffic size.
For app padding to work perfectly, app will have to know at least the MAC size. Otherwise, chunks will not fit into 1 packet.

Moreover, sending 1 gb in one "app message" will generally require 1 GB of RAM, because connection's "write" API method usually accepts a byte array.

99% of the time it's 4kb chunks, I checked this while doing debug of my connection class. As you know, HTTP will receive content-length first and then read chunks one by one until they fit the length, so huge size is not a transport layer problem.

But let's do some primitive calculations

Suppose we have an overhead of 16 bytes for MAC + 2 bytes for padding length (per packet) and transferring a 1 gb file and have 4 kb packet padding.

Max per-packet payload size will be 65517 bytes which will be used during the almost whole 1gb message.

We'll have to transmit (16 388 + 1 ) encrypted packets and the last packet (which is the only one to have padding)
will have 2 bytes of padding length, 4018 bytes of padding itself (to the nearest 4kb) and 49228 bytes of pure data

Which is ~ 0.03 % size overhead

Sounds good to me :)

So, the "1 mb" app alignment will be additionally aligned to the nearest 4 kb and the cost is 0.03 % overhead

Does this math sound ok?


-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Wednesday, March 01, 2017 11:40 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Padding & sending data during the handshake

On Wed, Mar 1, 2017 at 8:44 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> Sure, the code is here  https://github.com/go-noisetls/noisetls  sorry for its early quality.

At first glance, I wouldn't call it "NoiseTLS" because TLS is a distinct thing.


> 1) As for the application layer padding, not sure if we are talking about the same layer, but for example HTTP layer knows nothing about packet size which may not be fixed (if we a going to implement a renegotiation some day). So, the string "GET / HTTP/1.1" will always have the same size if we won't help at the packet layer.
> I know this looks weird, but we really looking forward to using REST 
> http over noise
>
> So, my vote is for adding the "padding size" API parameter. Size 2 bytes, so it's a tiny overhead if you disable it.
>
> I have also never seen any application-layer paddings and have no idea 
> of where would they be useful. When you know beforehand that all 
> packets are a multiple of 1024 or 4096, it will definitely remove some 
> amount of paranoia


I agree it's a tiny overhead, and easy to support for receiver.

I'm less sure what the API and code would look like for sender.  For example, suppose:
 - the server responds to the GET with a 1 GB file
 - the server sends the file via a series of NoiseSocket.write() calls with 2KB chunks
 - the server will like to pad the overall response size to the nearest 1 MB

How would all this work?  Maybe it would help to look at an API design / code samples.

> Sending "certificates" - also yes.  But in which message? NoiseXX first message is not authenticated in any way, what will be the rule of thumb? Together with "s" ?

Yep.

Trevor