[noise] Noise Socket draft review
scratch.net at gmail.com
Sat Apr 8 22:19:06 PDT 2017
Thanks a lot, Trevor, all of these makes sense. I will amend and give some feedback next week
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
Here's some comments on the Noise Socket draft:
- 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.
- ASCII art is inherently ugly, consider using Pandoc markdown which can insert images into HTML and PDF (that's how I did specs at ).
- "payload" is a term used in the Noise spec, so I would maybe use a different term here
- 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.
- Maybe move the HEX prologue to an Appendix at the end, which contains test vectors?
- 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.
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.
- I would delete this, and not include rekeying.
- 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.
Initialize(keypair or None)
SendClientHello -> RecvClientHello
RecvServerAuth <- SendServerAuth
SendClientAuth -> RecvClientAuth
Send <-> Recv
Where all the Send calls take a payload, and the Recv calls return a payload. Something like that?
simplier -> simpler
+and+ easier to implement
internaly -> internally
amount -> number
Noise mailing list
Noise at moderncrypto.org
More information about the Noise