[noise] Noise Socket draft review

[Alexey Ermishkin]

Thanks a lot, Trevor, all of these makes sense. I will amend and give some feedback next week

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