[noise] Noise Socket draft review

[Trevor Perrin]

Hi Alexey,

Here's some comments on the Noise Socket draft:

https://github.com/noisesocket/spec/blob/master/noise_socket.md


Section 2
----------
 - I would remove discussion of Noise_IK and 0-RTT for now.
 - If we're getting rid of null public keys, then you could just talk
about "dummy" public keys.

Section 3
-----------
 - ASCII art is inherently ugly, consider using Pandoc markdown which
can insert images into HTML and PDF (that's how I did specs at [1]).
 - "payload" is a term used in the Noise spec, so I would maybe use a
different term here

Section 4
----------
 - You say that the sub-messages each "corresponds to a concrete Noise
protocol".  But that's not necessarily true, it would be possible to
have sub-messages corresponding to non-Noise protocols.
 - Variable names are confusing.  It's Ps for message size, but Tl for
type length, and Ml for message length?
 - L bytes string indicating message type T?  Is L the same as Tl?
 - The ASCII diagram here is confusing as well.
 - The first and second messages should be split into separate
document sections, or the "following fields" should be placed in a
table or something, the structure of this section is hard to follow.
 - Remove the discussion of "Additional data" and Noise_IK for now.

Section 5
----------
 - Maybe move the HEX prologue to an Appendix at the end, which
contains test vectors?

Section 6
-----------
 - You disallow people from sending unencrypted payloads in the first
message, but I don't think that's necessary, maybe people are willing
to send things like SNI or other protocol negotiation in the clear.

Section 8
----------
This seems like a good example of the TLS-style complexity we are
trying to avoid:
 - Do we really need multiple channels of data?
 - Do we need to negotiate max packet size? In an earlier discussion
Rhys and I liked the idea of allowing the API to set max fragment
sizes, but not have this be auto-negotiated, as most people won't need
this.
 - I'm not convinced we need padding at this layer, but I'd like to
look more at the API and use cases to help answer that.

So I wonder if the complexity here could be removed or radically cut down.

Section 10
-----------
 - I would delete this, and not include rekeying.

Other
------
 - You should probably make this document self-contained, i.e. present
the full sequence of crypto operations.  Adopters want to see a simple
list of steps, they won't want to read the 40-page Noise spec.
 - You might want to add a section of test vectors
 - There should probably be a section discussing a recommended API.
For example:

    Initialize(keypair or None)
    SendClientHello -> RecvClientHello
    RecvServerAuth <- SendServerAuth
    SendClientAuth -> RecvClientAuth
    Send <-> Recv

    GetPeerPublicKey()
    SetMaxMessageSize()

Where all the Send calls take a payload, and the Recv calls return a
payload.  Something like that?


Minor
------
simplier -> simpler
+and+ easier to implement
internaly -> internally
amount -> number

Trevor

[1] https://whispersystems.org/docs/