[noise] NoiseLink customization

[Trevor Perrin]

On Thu, Feb 15, 2018 at 4:54 PM, Trevor Perrin <trevp at trevp.net> wrote:
>
> Thanks for bringing this up, we need to dive back into NoiseSocket /
> NoiseLink.  Figuring out the right layers and terminology between
> (NoiseSocket, NoiseLink?, other things?) still has a lot of open
> questions.


I think the NoiseSocket / NoiseLink work has been slow partly due to
us not having a clear architecture to fit everything into.

Let's try to brainstorm a high-level plan, then see if we can make
tentative decisions and just create some trial specs around it,
because I think filling in the details - once we have a plan - will
not be that hard.


There are maybe 3 layers to consider, from highest to lowest:

 (1) Negotiation Language
 (2) Noise Protocols
 (3) Framing / Encoding Layer

Our core spec focuses on (2), whereas NoiseSocket focuses on (3).

We've discussed having some protobuf-based Negotiation Language.  If
we defined such a thing, and combined it with NoiseSocket, we'd have a
"family" of protocols which are negotiation-compatible but not
necessarily interoperable.

By "family" I mean something like SSL/TLS.  All SSL/TLS parties can
negotiate, even if they will discover during negotiation that they
can't interop because they don't support the same versions /
ciphersuites / extensions.

A "profile" would be an interoperable instance of a family.  So for
example "TLS 1.2" would be a profile, where interop is expected.

---

Under this plan we'd continue to work on NoiseSocket, focusing on it
as an initial instance of a "Framing / Encoding Layer".  In other
words, we should define NoiseSocket to support an API that could be
implemented by different Framing / Encoding Layers in the future
(similar to how we've approached SymmetricState).

This plan also suggests some new specs, which I'll try some names for:

 * NoiseLingo:  This could be our initial example of a "Negotiation
Language".  NoiseLingo would describe a menu of protobuf-based
request/response fields that a protocol designer could select from to
negotiate things like (Noise Protocol, certificates and signatures,
max message sizes, rekey, etc).   But no-one is required to use all
the NoiseLingo fields.

 * NLS ("NoiseLingoSocket"):  The family of negotiation-compatible
protocols using NoiseLingo and NoiseSocket.

 * NoiseLink:  This would describe an initial set of NLS profiles
(e.g. "NoiseLink_25519_ChaChaPoly_BLAKE2s" might be NoiseLingoSocket
using the XX pattern without any additional NoiseLingo options).
NoiseLink would be a simple starting point / entry into using Noise:
it might be all you need, but if not it's easy to modify it by using
NoiseLingo to negotiate different Noise Protocols or options.

So we'd end up with NLS-compatible endpoints that could support
different NoiseLink profiles (or other NLS profiles), and endpoints
would interoperate if they supported the same profile.

That's a lot of concepts and terminology, but I think the actual work
to define these things is not that great, and we have most of the
ideas we need scattered around in mailing list threads...


Trevor