[noise] Noise Socket draft review
trevp at trevp.net
Sat Apr 8 15:55:27 PDT 2017
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
- 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
More information about the Noise