<div dir="ltr">Makes perfect sense. :)</div><div class="gmail_extra"> <div class="gmail_quote">2017-11-10 0:28 GMT+01:00 Trevor Perrin <<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 9, 2017 at 9:30 PM, Piotr Lizończyk <<a href="mailto:piotr.lizonczyk@gmail.com">piotr.lizonczyk@gmail.com</a>> wrote: > Separate document sounds reasonable - choosing to follow another philosophy > for structuring negotiation data contents wouldn't mean diverging from > NoiseSocket spec at all. Yeah, exactly - there's lots of possible languages for negotiation, versioning, etc, so NoiseSocket would be independent from that. > 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. Good question: Should the client advertise a single list of Noise protocols she supports, or separate lists for pattern, DH, cipher, hash. Earlier I suggested separate lists [1]. But now I'm leaning towards a single list as the best starting point. It gives us maximum flexibility, since a list of protocol strings could contain anything, including names that wouldn't fit into a pattern/DH/cipher/hash breakdown: "Noise_XX_25519_DiscoKeccak", "NoiseV2_XX_25519_AESGCM_SHA256", "TLS_13_25519_AESGCM_SHA256", etc > By the way, had a quick glance at TLS's CLIENT_HELLO - it has session_id > field in it As David said, sending a SessionID / Session Ticket is how the TLS client identifies a PSK for PSK-based resumption. If we do 0-RTT connections with public keys (e.g. ?K patterns), instead of PSK resumption, we don't need it. But at some point we'll hopefully spec out PSK resumption, probably like [2], and that will require the client to send a SessionID / Session Ticket 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. What I'm thinking is we can describe the contents of our default negotiation_data in abstract terms that can be translated into protobufs, XML, JSON, or your favorite encoding language. Then we get parsing and extensibility mostly for free, and higher-level protocol designers can use whatever they're already using. Make sense? Trevor [1] <a href="https://moderncrypto.org/mail-archive/noise/2017/001211.html" rel="noreferrer" target="_blank">https://moderncrypto.org/mail-archive/noise/2017/001211.html</a> [2] <a href="https://moderncrypto.org/mail-archive/noise/2017/001215.html" rel="noreferrer" target="_blank">https://moderncrypto.org/mail-archive/noise/2017/001215.html</a> </blockquote></div> </div>