[noise] Signatures and handshake payloads (was Re: Noise @ Highload++ in Moscow)
Trevor Perrin
trevp at trevp.net
Tue Nov 14 14:57:40 PST 2017
On Tue, Nov 14, 2017 at 8:51 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>> For future-proofing I think we should encourage extensible encodings
>> in handshake payloads (protobufs, JSON, etc).
>
> At the moment I don't have versioning in place, so I don't think it is
> going to be an issue. As for more complicated things, the verifier
> takes the whole payload and can do whatever it wants with it. That
> includes parsing a protobuf structure if the peer wants to do that.
> I'm really not keen on parsing anything. I like how Wireguard keep
> things simple.
Wireguard is tailored to its use case, though.
Once you start talking about a "drop-in", "plug-and-play" protocol
that anyone can use for different cases, I think extensibility becomes
more important. So there's a tension between "minimalism" and
"general-purpose, easy-to-use".
> But I think there are definitely good arguments in
> favor of something like protobuf and it is indeed a discussions we
> should have. I'll probably come back to that once I've looked more at
> NoiseSocket though.
Cool.
> Another good question to ask is what is Noise trying to solve? Will
> things like SNI or X.509 ever be relevant for Noise?
I think Noise-based protocols should be capable of anything other
2-party key agreement protocols do (SSH, QUIC, IPsec, TLS, DTLS,
CurveCP, MinimaLT, WPA, etc).
So if you're contacting an IP address that might be multiplexing
different servers you might need something like SNI. If you have an
X.509 PKI authenticating your static keys you might need to send cert
chains in handshake payloads.
Trevor
More information about the Noise
mailing list