[noise] Simple 1-RTT protocol

[Alexey Ermishkin]

Hi, Trevor,

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.

> 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"?
If so, it looks like our approach with multiple sub-messages, only now we have only single. 
I like this one. It allows us to use Noise protocol strings as identifiers and respond with something meaningful if we don't understand what client sends  


-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Wednesday, June 14, 2017 9:45 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Simple 1-RTT protocol

On Wed, Jun 14, 2017 at 8:13 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> At Virgil Security (virgilsecurity.com) we develop high-level crypto 
> SDKs and we want Noise to be TLS that works with our PKI on backend 
> between microservices and, from the other side, in Iot Devices like 
> smart bulbs and all sorts of others. And I am personally responsible 
> of bringing this to life)
>
> So, we would like servers to be able to talk to each other as well as with IoT.
> One problem that I see here is while we prefer AES on servers due to hardware acceleration, we would like to use Chacha on IoT.
[...]
> That's why I want to use IK together with XX , to be able to use TLS without keep-alive, x.509, but with the same level of security and much-much lower overhead.
>
> Hope that it explains my intensions.


Sure, thanks!

To explain my intentions more, my goal right now is a protocol (with
spec) that demonstrates how simple Noise can be, works for some basic use cases, and is easy to extend.

Maybe we should see if there's a base protocol that meets my goals of simplicity, but is extensible for your goals of (IK and XXfallback; ChaChaPoly or AES).

I think the issue is choosing versioning and extension mechanisms that are both simple and flexible.  Some thoughts:


Another versioning mechanism would be for both client and server to send a version.  The server normally echoes the client's version.
However some client versions might signal "server's choice", e.g.
client sends:
  version 1 = AESGCM
  version 2 = ChaChaPoly
  version 3 = server's choice of version 1 or 2

Or:
  version 1 = XX
  version 2 = XXfallback
  version 3 = IK (so server's choice of version 2 or 3)


This wouldn't allow a client to advertise new choices with an old server (the older server wouldn't recognize the new version).  Perhaps we could live with that, since:
 * The client could use its cleartext_payload to indicate additional choices in a backwards-compatible way, assuming old servers ignore the payload, or ignore unrecognized fields in the payload.
 * The server could also use its response payload to indicate it would have supported additional choices, allowing the client to re-start the handshake if it wants.

Another idea might be to allow uninterpreted "reserved" data at the beginning of every payload, including the first cleartext payload:

 - reserved_len (2-byte len)
 - reserved_data
 - payload

This might serve 2 goals:

 * Suppose the application developer mismanages the cleartext_payload, e.g. requires it to be empty, or to contain some data structure which is not extensible.  The reserved area would still give them a place to advertise options or send other data, in a backwards-compatible way.

 * If not otherwise used, the reserved area can be filled with zeros for padding, which is something we had debated whether to add or leave for the application.  Again, this is a case where the application developer might forget to do padding, and then be able to retrofit it via the reserved field.

?

Trevor