<div dir="ltr"><div><br></div><div>Hi all,</div><div><br></div><div>Some thoughts on Noise document status, and what I hope we can accomplish in rest of year:</div><div><br></div><div> * I'd like to do a quick revision 34 in next few weeks to move the large tables from Section 7 and 9 into an appendix.</div><div><br></div><div> * We'd discussed refactoring a "minimalist" core document and moving things like modifiers, pipes, and crypto algorithms from the core into separate documents [1,2].  I think there's not enough momentum for such a major surgery, so we should just "tie off" the core document with its current contents and perform new work in extension documents.</div><div><br></div><div>This means the division between core and extensions will be "historical": the core spec will contain some modifiers (fallback, PSKs), and some crypto algorithms, but not others.  This division will make clear what's been widely deployed and reviewed, versus newer things.</div><div><br></div><div> * We should create a template for extension documents containing recommended document sections, scripts to run pandoc and generate output, etc, and move current extension documents to this template.</div><div><br></div><div> * We should define what the lifecycle and maturity levels are for extension documents.  For example, "unofficial" extensions could be linked from the wiki and would be under control of their authors, whereas "official" extensions would be linked on the website, live in the "noiseprotocol" Github repo, and I'd be responsible for editing and merging changes.  (I'm not sure about this, though - while I'd like to edit everything for quality control and to make text style consistent, maybe that's a bottleneck or more control than people want to give me). </div><div><br></div><div><br></div><div>I'd like to personally work on these extensions:</div><div><br></div><div> * NoiseSocket [3]:  Alexey and I made a good start on this, we should think more about [4] which may force us to generalize the fallback concept and how we handle notions of "initiator" and "responder" when the responder is making the decision to use a different protocol.</div><div><br></div><div> * Negotiation layer built on NoiseSocket ("NoiseLink"?):  We should define how exactly to advertise and negotiate the Noise protocol using the NoiseSocket "negotiation_data" fields. I'd like to see if we can define a simple approach that would port easily to different encodings (JSON, Protobufs, etc), perhaps like [5] but simpler.</div><div><br></div><div> * Hybrid forward secrecy:  Rhys has made a great start on this [6,7].  I think we should incorporate notation ideas from the thread [8].  A more difficult issue is that PQ algorithms might requires access to some sort of KDF/XOF [9].  Perhaps we should review recent submissions to the NIST contest and see if that makes requirements clearer.</div><div><br></div><div> * Advanced 0-RTT:  Currently Noise supports 0-RTT encryption based on static public keys.  We'd like to add support for PSKs derived from an original session (TLS-style), and also short-lived public keys (QUIC-style).  I think we have good ideas on how to do these [10].</div><div><br></div><div>There are other interesting extensions (e.g. David's work on Disco; eventual support for signatures and PAKE).  But the above have been discussed to the point that it's pretty clear how to move forward, so just writing specs and some trial implementations should give us rapid progress.</div><div><br></div><div>Trevor</div><div><br></div><div>[1] <a href="https://moderncrypto.org/mail-archive/noise/2017/001089.html">https://moderncrypto.org/mail-archive/noise/2017/001089.html</a></div><div>[2] <a href="https://moderncrypto.org/mail-archive/noise/2017/001201.html">https://moderncrypto.org/mail-archive/noise/2017/001201.html</a> </div><div>[3] <a href="http://noiseprotocol.org/specs/noisesocket.html">http://noiseprotocol.org/specs/noisesocket.html</a> </div><div>[4] <a href="https://moderncrypto.org/mail-archive/noise/2017/001267.html">https://moderncrypto.org/mail-archive/noise/2017/001267.html</a> </div><div>[5] <a href="https://moderncrypto.org/mail-archive/noise/2017/001211.html">https://moderncrypto.org/mail-archive/noise/2017/001211.html</a> </div><div>[6] <a href="https://github.com/noiseprotocol/noise_spec/blob/master/extensions/ext_hybrid_forward_secrecy.md">https://github.com/noiseprotocol/noise_spec/blob/master/extensions/ext_hybrid_forward_secrecy.md</a> </div><div>[7] <a href="https://github.com/rweather/noise_spec/blob/kyber/extensions/ext_kyber.md">https://github.com/rweather/noise_spec/blob/kyber/extensions/ext_kyber.md</a> </div><div>[8] <a href="https://moderncrypto.org/mail-archive/noise/2017/001151.html">https://moderncrypto.org/mail-archive/noise/2017/001151.html</a> </div><div>[9] <a href="https://moderncrypto.org/mail-archive/noise/2017/001254.html">https://moderncrypto.org/mail-archive/noise/2017/001254.html</a> </div><div>[10] <a href="https://moderncrypto.org/mail-archive/noise/2017/001215.html">https://moderncrypto.org/mail-archive/noise/2017/001215.html</a> </div><div><br></div></div>