[noise] Potential cleanups for a rev35?

[Justin Cormack]

On 5 August 2018 at 20:26, Trevor Perrin <trevp at trevp.net> wrote:
> We'd talked a little about doing a revision 35 soon after 34, just to
> cleanup a few things in the text:
>
> https://moderncrypto.org/mail-archive/noise/2018/001535.html
> https://moderncrypto.org/mail-archive/noise/2018/001547.html
>
> (1) Integrate PSK into text alongside other tokens, instead of having
> it in its own section?

I did come across someone who had somehow missed that this existed,
so I think this maybe makes sense, not sure.

> (2) Move security properties tables into appendix, so the main text is
> more readable?

Maybe now the deferred ones are there, not sure.

> It's not completely obvious that those are good cleanups: there are
> some things I like about having the PSK discussion self-contained, and
> about emphasizing the security tables.
>
> But we could try drafting those and see how they look.
>
>
> There's a few other cleanups we could consider:
>
> (3) Remove SetNonce() in favor of a cleaner treatment of out-of-order
> nonce handling, per recent discussion with Jake, Justin, and Luke.
>
> (4) I'm wondering whether "transport" in "transport phase" is the best
> name, since the term "transport" is pretty overloaded in network
> protocols.  TLS prefers "traffic" for this phase, we could consider
> that?

That sounds an improvement.

> (5) Our distinction between "handshake phase" and "transport phase"
> isn't very explicit that some handshakes rely on the first transport
> messages to achieve their full security properties.  Noise Explorer
> calls these "tokenless messages".  I wonder if we should do something
> cleverer with our terminology and phases here, but not really sure
> what...

I think it might help trying to explain about this earlier and more clearly,
especially if the security properties are moved later. Perhaps it needs
a more specific callout. It could be a problem if you are trying to provide
a generic library and you don't know the type of protocol that will be
running over it - for request response protocols it is generally not an issue
but where either side can send messages it may be.

Another option would be to explicitly include the tokenless message as part
of the handshake phase, so defining the handshake as finishing when the
properties are fixed. It is only I think a single message that is affected here.
That is a bit more drastic, as it looks like more of a change, although arguably
its not a real protocol change.

Justin