[noise] Signatures and handshake payloads (was Re: Noise @ Highload++ in Moscow)

[Trevor Perrin]

On Tue, Nov 14, 2017 at 12:02 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>
> For my Noise-plug-and-play implementation this is what I'm currently
> doing. I'm trying to find the simplest way to tackle authentication.
> I'd be happy to discuss about these:
[...]
> * If a peer needs to authenticate itself during a handshake, it will
> send the signature as the encrypted payload of its last message
> pattern (the one that sends the static key).

Makes sense, but I'll pick at one thing:


> * I do not use any format (like JSON) anywhere. I'm just assuming that
> the concatenation of all payloads sent during the handshake is the
> signature in bytes.
[...]
>
> I can see how formatting might be useful, but I'm currently not using
> the handshake's payloads for anything else than sending a proof so it
> is not needed in my case.


For future-proofing I think we should encourage extensible encodings
in handshake payloads (protobufs, JSON, etc).

Protocols tend to evolve.  It's quite possible you'll next want
certificate chains or usernames or SNI or version numbers or something
else in your payloads.

Particularly for a "plug-and-play" implementation that might be used
by naive users in different ways, it seems much safer to start with
extensibility.


I'm not sure it makes sense for us to bikeshed our favorite encoding
language for this use.  But if we want interop at these higher levels,
maybe it does!  In that spirit:

Protobufs (v3) specifies a JSON mapping [1], so maybe taking a simple
subset of the protobufs language would give us something that's fairly
readable and easy to work with, has good language support, and has
good binary and string (JSON) encodings?

Trevor

[1] https://developers.google.com/protocol-buffers/docs/proto3#json