[noise] Document status and plans

[Trevor Perrin]

Hi all,

Some thoughts on Noise document status, and what I hope we can accomplish
in rest of year:

 * 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.

 * 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.

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.

 * 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.

 * 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).


I'd like to personally work on these extensions:

 * 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.

 * 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.

 * 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.

 * 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].

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.

Trevor

[1] https://moderncrypto.org/mail-archive/noise/2017/001089.html
[2] https://moderncrypto.org/mail-archive/noise/2017/001201.html
[3] http://noiseprotocol.org/specs/noisesocket.html
[4] https://moderncrypto.org/mail-archive/noise/2017/001267.html
[5] https://moderncrypto.org/mail-archive/noise/2017/001211.html
[6]
https://github.com/noiseprotocol/noise_spec/blob/master/extensions/ext_hybrid_forward_secrecy.md

[7]
https://github.com/rweather/noise_spec/blob/kyber/extensions/ext_kyber.md
[8] https://moderncrypto.org/mail-archive/noise/2017/001151.html
[9] https://moderncrypto.org/mail-archive/noise/2017/001254.html
[10] https://moderncrypto.org/mail-archive/noise/2017/001215.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20171004/77583e40/attachment.html>