[noise] Noise Socket draft review

[Alexey Ermishkin]

Hi Trevor,
Please find the updated draft at the same location:
https://github.com/noisesocket/spec/blob/master/noise_socket.md

I removed everything related to IK, 0-RTT, ascii-art and variable names.  I also tried to leave "payload" only where it refers to noise payloads.

Also, added test vectors and their description to the doc

As for complexity (previously, Section 8), we can make all field types except "Data" optional, it will not break backwards compatibility, a peer can just ignore unknown fields.

My idea is that we define a set of "features" which may or may not be supported by a concrete implementation, so that people didn't have to invent their own padding or size negotiation if they need it.

I'm still thinking about API doc & including pieces of Noise spec into NoiseSocket spec, it's not yet ready.

-----Original Message-----
From: Noise [mailto:noise-bounces at moderncrypto.org] On Behalf Of Trevor Perrin
Sent: Sunday, April 09, 2017 3:55 AM
To: noise <noise at moderncrypto.org>
Subject: [noise] Noise Socket draft review

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/
_______________________________________________
Noise mailing list
Noise at moderncrypto.org
https://moderncrypto.org/mailman/listinfo/noise