[noise] Simple 1-RTT protocol

[Trevor Perrin]

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