[noise] Simple 1-RTT protocol

[Trevor Perrin]

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