[noise] Simple 1-RTT protocol

[Alexey Ermishkin]

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.
Early tests of my PoC showed 5-10x faster handshake times compared to TLS 1.2 using XX and IK.

We also plan to use it _with_ signatures applied to dummy static public keys, however without X.509. But that's independent from protocol spec and can be implemented with any design that we'll produce.

Packed in a library this should be an easy way to add transport security to backend where there's usually none.

>From the other hand we have IoT guys who hate TLS but able to do sign/verify/encrypt crypto and have no proper use for it. We want to give them the same spec or a library they could use to communicate to the servers without tls but with the same amount of security and usability.

So, back to our discussion:

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.

> 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. 

P.S.
"NoiseLink" does not sound like a protocol or tech to me. More like a music group ) https://soundcloud.com/noise-link


-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Monday, June 12, 2017 1:02 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 6:46 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> I see following disadvantages:
> 1) Using abstract "version" makes all implementations incompatible by 
> definition

I'd put it a little differently:

Implementations already have to agree on (DH, Cipher, Hash) to be compatible.  Having a version byte adds another thing to agree on:
(Version, DH, Cipher, Hash).

Applying Noise to an application protocol (e.g. SMTP) probably requires agreeing on even more (e.g. port number and/or SMTP verb; contents of handshake payloads).

So agreeing on version numbers might not be much extra burden?


> 2) No standard way to use IK or Pipes

Having a single version field lets you add these later.  But I'd like something extremely simple to implement, integrate into applications, and reason about, so I would avoid 0-RTT handshakes with complicated fallback and security properties.


> This reduces the usability to a very limited number of cases where everyone will be able to play in their own sandbox only. I thought of Noise_TLS/Socket/Link/whatever to be a more general purpose transport layer protocol.

I'd like it to be general purpose, but also very simple.


> My suggestions:
> 1) We could still use string identifiers instead of version number, this will add compatibility.

That's an option.  It does mean larger messages.

We're designing this in a use-case vacuum, so it's hard to weigh the tradeoff of message size versus the hassles of a version number.  But if we want this general-purpose, it might be worth thinking about constrained platforms (e.g. smartcards, SCADA, IoT) where a 30-40 byte initial message might be better than 60-100 bytes.


> 2) I don't like the idea of generating multiple sub-messages either. 
> To avoid the necessity of executing multiple handshakes and generating  
> multiple sub-messages, we could specify the ClientHello message for XX 
> as
>  -  List of strings of names of supported protocols
>  -  Public key

XX handshakes can also differ in public key (eg 25519 vs 448).


> 3) All other protocols (IK) where first message is not a plain public key must always send only a single Noise message during ClientHello.
> So it's either of two
>  - a  list of protos + public key
>  -  protocol name +noise message

Hmm, that's special-casing the case where the client supports different cipher+hash for a fixed XX+DH.  I think it would be simpler and more consistent just to have a single mechanism, which I'm suggesting as: client chooses the version, and server can reject it, or accept it and optionally notify the client of other versions (using application data).


> As for the name.. NoiseTransport, maybe?

Hmm, that's probably better than NoiseSocket.  We already have a "transport phase" and "transport messages", though.

Also, that sounds like we're trying to reproduce all the complexity of TLS and make a drop-in replacement, which isn't really the goal (e.g.
we don't support signatures, so you couldn't just drop in your existing RSA or ECDSA keypairs and certs).  You're not liking "NoiseLink"?


Trevor