[noise] Potential cleanups for a rev35?

[Justin Cormack]

Another option would be to have a modifier that means "add another handshake
round with no tokens", eg

KN:
     -> s
     ...
     -> e
     <- e, ee, se

KNtokenless:
     -> s
     ...
     -> e
     <- e, ee, se
     ->


On 5 August 2018 at 23:47, Justin Cormack <justin at specialbusservice.com> wrote:
> 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