[noise] Simple 1-RTT protocol
scratch.net at gmail.com
Tue Jun 20 03:30:09 PDT 2017
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
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.
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.
version 1 = AESGCM
version 2 = ChaChaPoly
version 3 = server's choice of version 1 or 2
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)
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.
More information about the Noise