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

Alexey Ermishkin scratch.net at gmail.com
Sun Feb 5 13:34:02 PST 2017

By n1 (first point in my list) I thought we could use not only protocol names but also add extra info like max packet size if needed. We have 255 bytes, we can even use json for that :)

But yes, I agree with "protocol name only" by default. 

As for the API - also yes. I can't stop thinking of "transparent re-handshake" mechanism and already have an Idea of how it can be achieved. It will definitely involve some API work and needs to be described separately.

-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Monday, February 06, 2017 2:19 AM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: Rhys Weatherley <rhys.weatherley at gmail.com>; David Wong <davidwong.crypto at gmail.com>; noise <noise at moderncrypto.org>
Subject: Re: [noise] A simple and safe TLS/TCP-like protocol

On Sun, Feb 5, 2017 at 11:09 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> So, as an intermediate summary I can see that
> 1) We'll use strings with 1 byte length instead of versions. It allows us to specify cipher suites, patterns and whatever else.

The Noise protocol name specifies these things, so I'd just put in the full protocol name (e.g. "Noise_XX_25519_ChaChaPoly_SHA512").

You could argue for skipping the first 5 bytes ("Noise") but I would leave them:

 * It allows extending the version negotiation to include non-Noise protocols.  E.g. your initial message could offer some Noise protocols, but also "TLS_13" or something else.

 * Makes packet captures more readable.

> 2) Maximum packet size should be configurable. Via n1 or other 
> mechanisms

Agreed that I like Rhys's idea of making this configurable via an API call.  Which highlights that we need to define a NoiseSocket API, not just the on-the-wire protocol.

Not sure what you mean by n1?

> What will be a prologue then? A concatenation of all "message type" strings from the first message?

Yeah, I think that's the best we can do.  Since the initial messages might depend on the prologue (e.g. with NoisePSK), we can't make the prologue contain the initial message contents.

But we could set the prologue to:
 - 1-byte = number of version strings (N)
 - N times:
   1-byte = length of version string
   <version string>


More information about the Noise mailing list