[noise] Padding & sending data during the handshake
trevp at trevp.net
Wed Mar 1 07:57:10 PST 2017
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
> 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
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.
More information about the Noise