[noise] expected length of messages during handshake

[Trevor Perrin]

On Fri, Nov 3, 2017 at 6:13 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>
> So, I have implemented a library to do some Noise_** patterns
> transparently for the application. I had to add a 2-byte length field
> to make it work, as well as some signature code to make X/I pattern
> work. The changes were extremely minimal, but it works. Developers
> should be able to choose what pattern they want to use (good
> documentation should provide guidance) and have the thing run on both
> their clients and servers. At the moment, there is only one such
> implementation though, and in Golang. It makes it really hard for
> developers to have a plug-and-play protocol they can use. Most
> libraries out there seem to implement the foundation for something
> like this to work, but without a framing layer it won't be compatible.

If you don't want negotiation, NoiseSocket framing should be pretty easy:

 * Handshake messages start with a 2-byte length field for
"negotiation_data".  Implementations skip over and ignore this data
when receiving, and set it to zero-length when sending.

 * Handshake messages next have a 2-byte length field for the Noise
message, followed by the Noise message.

 * Transport messages have a 2-byte length field, followed by the Noise message.

 * The plaintext inside encrypted payloads starts with a 2-byte length
field to describe the length of the "body".  Data after the body is
padding and is ignored.

This lets you add negotiation later.  For example, new clients can
advertise they support new ciphers in negotiation_data.  Old servers
will ignore the negotiation_data, but newer servers can send
negotiation_data to select the new cipher.

(Defining a language for the contents of negotiation_data is not part
of NoiseSocket, but is something I plan to work on soon.)


> Of course the changes could be done, but this is extra (and
> dangerous?) work for developers who are just in need of something that
> works.
> What is the way to go from there?

I'd like to see us experiment with NoiseSocket and see if it works as
the "recommended" framing for TCP-like cases.


> So I'll ask two questions here:
>
> * if NoiseSocket is the way to have plug-and-play and compatible
> libraries, do we really need negotiation? do we really need fallbacks?
> etc... in a lot of use cases, the simplicity of Noise should suffice.

Some cases won't need negotiation (e.g. if you administer all
endpoints).  Some protocols might need minimal negotiation (just a
version number).  For cases like HTTPS, where clients and servers are
upgraded independently, you probably need more.

I think we should support all these cases.


> * if NoiseSocket is the way to go, should we make a push for
> implementers not to implement the core of the Noise protocol
> framework, but rather the NoiseSocket extension?

It's not an either/or, since NoiseSocket is built on top of the Noise core.

As for encouraging Noise libraries to also implement NoiseSocket or
any other Noise-based protocol:  I'd encourage people to experiment
with NoiseSocket.  But NoiseSocket is young, and probably needs a lot
more work and implementation/deployment experience before we have any
confidence that it's the right direction.

But to figure that out, we need to try it!

Trevor