[noise] expected length of messages during handshake

[Piotr Lizończyk]

Separate document sounds reasonable - choosing to follow another philosophy
for structuring negotiation data contents wouldn't mean diverging from
NoiseSocket spec at all.

I think that basic fields should include:
1) version (both noiseprotocol and noisesocket, i.e. spec revision).
Version of NoiseLink could be useful too.
2) initial noise protocol
3) noise protocols supported

Most reasonable format for 3) would consist of handshake
patterns/cipher/dh/hash supported (quite small in size), though it would
put some constraints on the user - inability to support only specific
combinations of those, not every possible combination of supported
algorithms. Not sure if it would have any reasonable usecase, but it's
worth considering at the early stage of design.

By the way, had a quick glance at TLS's CLIENT_HELLO - it has session_id
field in it and I think we can support channel binding the same way
(obviously give a warning NOT to use unsigned/nonencrypted handshake hash
in this field). I'd see this field as an optional one, so maybe we could
have "optional data field" at the end of negotiation data that could
contain such data. Maybe an overkill though.


2017-11-09 18:59 GMT+01:00 Trevor Perrin <trevp at trevp.net>:

> On Thu, Nov 9, 2017 at 11:04 AM, Piotr Lizończyk
> <piotr.lizonczyk at gmail.com> wrote:
> > I’ve recently started implementing NoiseSocket in Python noiseprotocol.
> > First thought: would be nice to have at least default proposed contents
> for
> > negotiation data. Otherwise we’ll likely end up with implementations
> freely
> > following structure in Alexey’s go-noisesocket (or e.g. mine if I decide
> to
> > come up with my own). Obviously, usage of this default structure won’t be
> > necessary, nor explicitly suggested.
>
> Yeah, I'm totally with you.
>
> I've been thinking of this as a separate document (maybe "NoiseLink"?)
> on top of NoiseSocket, that defines how the client can offer a list of
> named protocols that the server selects from.  Perhaps defined
> abstractly enough that we could instantiate it with protobufs, JSON,
> or others.
>
> I need to just start this document so we can critique it, will try soon...
>
> Trevor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20171109/5b8b102b/attachment.html>