[noise] Padding & sending data during the handshake

[Alexey Ermishkin]

Sure, the code is here  https://github.com/go-noisetls/noisetls  sorry for its early quality.

Some interesting places to look at:

protocols.go - a precalculation of what we support
handshake.go - composing first message, parsing & negotiation 
And the core - 
conn.go is a lil bit borrowed from Go's TLS implementation because it uses locking and memory management in a similar way

Back to our questions.

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

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" ? 

-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Wednesday, March 01, 2017 8:57 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 5:59 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> Good news - I implemented Noise Socket as per draft which supports 
> negotiation, XX and IK. It is an "honest" implementation which 
> initializes as many HandshakeStates as all combinations of 
> ciphersuites and patterns (8 for XX, 8 for IK in my case)

Cool, is code available?


> HTTPS over my NoiseSocket implementation runs at the same speed or a 
> bit faster (5%) than TLS 1.2. But of course it's still too early to 
> make conclusions.
>
> 2 more questions I'd like to discuss are:
>
> 1) Padding. Do we want one? I thought about adding to the beginning of 
> every transport packet contents:  <2 bytes len bytes to skip> <len 
> bytes zeroes> to achieve multiples of 1024 or whatever

Good questions.  For a few reasons I think padding might be better left to the application:

(1) The application probably needs to be involved anyways (e.g. to enable/disable padding, and set the parameters).

(2) The application messages probably already have some encoding (JSON, XML, etc) for which it's easy to add an ignored padding field without adding new parsing code.

(3) Because application data is being streamed across multiple transport messages, you might want padding on an "application message"
basis rather than a "Noise transport message" basis.

For example, the server might want to pad an application message to 70K, so you'd have to pad the first Noise transport message to 65535 and the second message to 70K - 65535.  So the API would have to be more complicated than just "pad every Noise message".


> 2) Do we really want to allow sending transport data inside handshake 
> payloads ? It will at least mess with future handshake parameters. It 
> will also depend on the pattern at which stage can we safely send 
> anything. I know about the comparison table in the Noise spec but 
> anyway, worth mentioning.

I think we need to allow servers and clients sending certificates when they authenticate, and probably also clients sending things like SNI, or other negotiation parameters, in their first message.

And if you want to get value from Noise_IK then of course you have to do this.

But it should probably have a very different API then the application data, so it's clear that the security properties are different.

Trevor