[noise] Simple 1-RTT protocol

[Trevor Perrin]

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