<div dir="ltr">Separate document sounds reasonable - choosing to follow another philosophy for structuring negotiation data contents wouldn't mean diverging from NoiseSocket spec at all.<div><br></div><div>I think that basic fields should include:</div><div>1) version (both noiseprotocol and noisesocket, i.e. spec revision). Version of NoiseLink could be useful too.</div><div>2) initial noise protocol</div><div>3) noise protocols supported</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-09 18:59 GMT+01:00 Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Nov 9, 2017 at 11:04 AM, Piotr Lizończyk<br>
<<a href="mailto:piotr.lizonczyk@gmail.com">piotr.lizonczyk@gmail.com</a>> wrote:<br>
> I’ve recently started implementing NoiseSocket in Python noiseprotocol.<br>
> First thought: would be nice to have at least default proposed contents for<br>
> negotiation data. Otherwise we’ll likely end up with implementations freely<br>
> following structure in Alexey’s go-noisesocket (or e.g. mine if I decide to<br>
> come up with my own). Obviously, usage of this default structure won’t be<br>
> necessary, nor explicitly suggested.<br>
<br>
</span>Yeah, I'm totally with you.<br>
<br>
I've been thinking of this as a separate document (maybe "NoiseLink"?)<br>
on top of NoiseSocket, that defines how the client can offer a list of<br>
named protocols that the server selects from.  Perhaps defined<br>
abstractly enough that we could instantiate it with protobufs, JSON,<br>
or others.<br>
<br>
I need to just start this document so we can critique it, will try soon...<br>
<span class="HOEnZb"><font color="#888888"><br>
Trevor<br>
</font></span></blockquote></div><br></div>