[noise] Simple 1-RTT protocol

Alexey Ermishkin scratch.net at gmail.com
Mon Jun 12 02:07:22 PDT 2017

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. 

"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"?


More information about the Noise mailing list