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

[Trevor Perrin]

About version-handling for a NoiseSocket:

I was thinking any user of a NoiseSocket would define their own
version map, i.e. 0 = Noise_XX_25519_AESGCM_SHA256.

It's hopefully rare that people need more than one version, but if you
want to switch to a different cipher you define 1 =
Noise_XX_25519_ChaChaPoly_SHA256 and so on.


Let's call that option (1), and consider a few other options:


(2) Global registry for ciphersuite numbers, e.g.

0x0001 = Noise_XX_25519_AESGCM_SHA256
0x0002 = Noise_XX_25519_AESGCM_SHA512
0x0003 = Noise_XX_25519_ChaChaPoly_SHA256
0x0004 = Noise_XX_25519_ChaChaPoly_SHA512
...


(3) Global registry for "a la carte" crypto numbers:

DH: 0x0001 = 25519, 0x0002 = 448, ...
Cipher: 0x0001 = AESGCM, 0x0002 = ChaChaPoly, ...
Hash: 0x0001 = SHA256, 0x0002 = SHA512, ...


(4) Strings:

"Noise_XX_25519_AESGCM_SHA256", ...


>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, even for experimental
or odd uses (e.g. Adam Langley on the "tyranny of magic number
registries" [1]).

So that leaves (1) vs (4).  The main NoiseSocket goal is simplicity of
use, so I think I'm leaning towards (4).

The reason is that using explicit strings removes one more thing the
user has to think about (the version map).  Instead, the user just
decides "I want to use 25519_ChaChaPoly_BLAKE2b and
448_ChaChaPoly_BLAKE2s", and that immediately translates into a
protocol.

Also, it makes it easy to point different NoiseSocket implementations
at each other and either get interop or easily see what's wrong,
without version numbers in the way.

While this is more verbose, for a typical protocol that only offers
one or a few options over TCP the extra bytes are pretty
insignificant, I think.


To Alexey's objections:

On Fri, Feb 3, 2017 at 1:08 PM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> We could get all the needed cipher suite info from the string but I still
> don't like the idea of parsing strings.

If the API requires the user to specify the list of protocol names
they support, then you don't have to parse the transmitted strings,
just compare them.


> It's pretty easy to generate all
> supported ciphersuite combinations which should not be many, and use hashes
> instead.

I don't see how that's much different than just sending strings, you
could still hash the strings and then look them up in a hashtable or
something, but that's an implementation choice.


Trevor


[1] https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit