[noise] Simple 1-RTT protocol

[Alexey Ermishkin]

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.

But IoT will definitely use something other than REST HTTP (mqtt), so, having lost of unneeded stuff in the first message might be an unnecessary overhead.

As for performance, I ran a multiple handshake test between two servers using TLS 1.2 and Noise. It is an important test because keep-alive is not always available and using TLS session cookies is also a big problem in distributed systems.
And my test showed that Noise_XX was about 5 times faster than ordinary TLS. IK was even faster.

Golang does not support TLS 1.3 yet, so I can't test it, but anyway, ED25519 certs are far away and we don't use x.509 

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.



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

On Mon, Jun 12, 2017 at 9:07 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> We are definitely not designing this in vacuum as there are alive people who want fast TLS between services but with much lower handshake overhead and without x.509. This is what I believe Noise<your-word-here> Is able to achieve.

I agree that's a good goal.

But I'm not sure people with concrete, important use cases for this are here talking to us.  For example, WireGuard's been giving feedback on PSKs and other things, which is helpful.  I wish we had more potential users for the simple 1-RTT protocol.

(I think you have some use for it?  Do you have pointers or more explanation?)


> Early tests of my PoC showed 5-10x faster handshake times compared to TLS 1.2 using XX and IK.

I'm not sure what you're measuring?  TLS has a lot of options, e.g.
TLS 1.2 with the "false-start" trick can achieve 1-RTT, and the
(draft) TLS 1.3 has 0-RTT and can use 25519.

Certainly Noise can give simpler handshakes, but the performance comparison has lots of factors (and things like false-start and 0-RTT involve security tradeoffs).


> About strings:
>
>> That's an option.  It does mean larger messages.
> Modern IoT frameworks (ex:amazon) use rsa, x509 and MQTT via TLS, so using string instead of an int does not seem like a big deal. It will anyway be much lighter than people already have to use.

Could be true, but "IoT" covers a range of things.  I also brought up smartcards and SCADA.  I don't know that much about ultra-low-end, bandwidth-constrained environments, so I'm not sure how to judge this trade-off.


>> XX handshakes can also differ in public key (eg 25519 vs 448).
> Protocol names like Noise_XX_25519_AESGCM_SHA256 do define public key format, so server will understand what client sends. However there might be several tuples of <prototols list>:<public key> in ClientHello if we wanted to.
>
> The reason for all this is to avoid "server rejects" & disconnects.

Doesn't that just end up with something like current NoiseSocket, where you're sending a list of initial "sub-messages", each corresponding to a list of potential protocol names the server could choose?

That's more complicated code, API, and prologue-handling (because 0-RTT encrypted messages would depend on the prologue, so you can't just hash everything into the prologue), and larger initial messages.

Having the client just send a single version with a single version byte is much simpler, so my question is whether the more complicated versioning is worth the cost.

Trevor