[noise] Simple 1-RTT protocol

[Trevor Perrin]

On Tue, Jun 20, 2017 at 10:30 AM, Alexey Ermishkin
<scratch.net at gmail.com> wrote:
>
> When we tried to introduce fields and field types for NoiseSocket, the main counterargument was that we'll have to maintain the list of field types somewhere. I see similar potential problem with versions, though I like the simplicity.

I was thinking about application-specific version numbers here.  For
global identifiers I think global number registries are awkward, but I
think application-specific version numbers are fine.


>> Another idea might be to allow uninterpreted "reserved" data at the beginning of every payload, including the first cleartext payload:
> Have I understood you correctly, this data is not Noise's paylad data, just a reserved "space"?

It would be Noise's payload data, but the application would have to
access it through a special API, so it gives the application an extra
space to put padding or to put extensions.  I'm not sure that's worth
the effort.

Here's another version scheme, what if we just did this with Noise_XX?

 * Client sends 1-byte client_version, 1-byte client_options
 * Server responds with 1-byte server_version
 * server_version == client_version unless the client_version or
client_options indicates server choice
 * unrecognized client_features or server_features are ignored
 * server's API is a list of (client_version -> server_version,
Noise_protocol) choices, as well as a more specific list of
(client_version, client_options -> server_version, Noise_protocol)
choices.  The more specific choices take priority.

So the client_options can signal support for new versions in a
backwards-compatible way.  Once the client is ready to break
compatibility, it increments client_version?

Trevor