[noise] PerformHandshake() Function

[dawuud]

Since Katzenpost uses Noise XX we have ourselves a function called handshake.
Upon returns it means that both parties have performed the handshake.

https://github.com/katzenpost/core/blob/master/wire/session.go#L140-L289

If the noise library were to perform this function then it would have to
take ownership of the connection type whereas it specifically avoids this by design.

I guess by synchronous you mean usage of blocking IO symantics which is all golang is capable of.
However Rust programmers had better be writing their protocols in a sans-IO manner so that they
can accomodate async IO as well as blocking IO.


On Mon, Jun 03, 2019 at 02:56:48PM +0200, Nadim Kobeissi wrote:
> Hello everyone,
> 
> In working with Noise implementations in production, we noticed something interesting: inside the HandshakeState object, the following functions currently exist:
> 
>     - Initialize(handshake_pattern, initiator, prologue, s, e, rs, re): initializes the state machine locally.
>     - WriteMessage(payload, message_buffer): writes a message with an optional payload.
>     - ReadMessage(payload, message_buffer): reads a message as written using the above function.
> 
> In addition to the above, it may be useful to add a new “PerformHandshake()” function. The simple goal of this function would be to advance the local Noise Handshake Pattern state machine of both parties to the point where they have dealt with all handshake messages and where the next message to be sent will be a transport message.
> 
> The usefulness of “PerformHandshake()” is in contexts where both parties can afford to perform a synchronous round-trip key exchange without issue. Imagine we are deploying IKpsk2 in a use case where both parties are expected to be online always. In that scenario, it is in both the initiator and the responder’s benefit to arrive to the transport message stage of the protocol as quickly as possible since transport messages will benefit from stronger confidentiality and authentication guarantees, and so calling “PerformHandshake()” before transmitting any real payloads of actual value could be beneficial.
> 
> Predictable question: “Why not leave this up to the implementer to do manually?”
> Answer: this actually seems to be a pretty common use case scenario from my experience. By implementing it directly within the Noise Protocol Framework specification, we can avoid an additional burden on users where they can also potentially get things wrong. We also make it easier for implementers to have a more user-friendly “out of the box” experience once a Noise implementation is prepared.
> 
> I’m not set on the name and so of course we can call this function anything we like in the event that this proposal garners popular support.
> 
> Interested to hear your thoughts,
> 
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
> Sent from office
> 
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise