[noise] Simple 1-RTT protocol
trevp at trevp.net
Mon Jun 12 01:01:40 PDT 2017
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
> 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
More information about the Noise