[noise] Negotiation and 0-RTT

[Trevor Perrin]

On Thu, Jul 6, 2017 at 8:55 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
>
> Is it possible we'll use 0-RTT with just another client_version? So that we would not have to send messages in parallel.

One issue is that I was thinking of using the initial cleartext
payload to contain any version advertisements about what other
versions are supported.  So if we do IK in parallel with XX, the XX
initial cleartext payload can still be used for that, and we can
fallback to XX if IK isn't decryptable:

Message 1:
 -> version for XX
 -> initial_message = XX, with cleartext version advertisements
 -> zerortt_message = IK

If we just send an initial IK message for 0-RTT, we don't have that
advertisement space (or we'd have to do something different):

Message 1:
 -> version for IK
 -> initial_message = IK


> I mean, this protocol leaves much to the app, including the meaning of versions. We will not be able to say: This is NoiseLink, read the spec and write compatible implementation.
> We'll have to write our own addition to it with meanings of versions, algorithms, supported patterns and so on.

That's true.  Part of the problem is that it's easy to standardize
statements like "client is using client_version", "server is using
server_version".

It's harder to standardize "client is willing to support versions
[XYZ]" because there's a lot of different but reasonable ways to
express [XYZ] - e.g. a maximum version number, a list of supported
versions, or separate lists of (DH, ciphers, hashes, patterns).  Also,
these could be encoded in various formats (JSON, Protobufs, etc).

So that's why I'm suggesting designing the lower-level versioning
separately, and leaving it to a higher layer to handle advertisements
in the cleartext payload.  It's possible there could be a separate,
higher-level protocol that standardizes payload contents, maybe we're
making a stack of protocols here?


> If so, then why just not say that (if we are the app):
>
> Version 1: XX_25519_AESGCM_SHA256
> Version 2: IK_25519_AESGCM_SHA256
> ...
> Version99: XX_Fallback...
>
> Does that sound reasonable?

I think it's fine (and a good idea) to have a map like this, but it
doesn't answer the question of how the client is advertising different
version choices in its first message, and how the server is choosing
them, so we still need some additional mechanism for that.

Trevor