[noise] NoiseSocket status and plans
davidwong.crypto at gmail.com
Tue Nov 21 15:36:50 PST 2017
I've taken a look at the spec and I see now that it is a very general spec:
* it mentions 0-RTT once without explanations on what it is or how it would work
* it does not define what patterns are used or what combinations of
patterns can be used
* it does not define what format is used for negotiation data
so is this another framework on top of the Noise protocol framework?
I had the idea that it was more "plug-and-play" than that.
> Length fields
> NoiseSocket uses 2-byte lengths for:
> (a) negotiation_data in handshake messages (for extensibility)
> (b) Noise message lengths (for framing)
> (c) The body length of encrypted payloads (for length-hiding)
Is a Noise message of 65535 bytes including all of this?
> The main alternative is to allow 4-byte lengths for (b) and (c) for
> "jumbo" transport messages, if both parties agree . This might
> improve efficiency for high-speed implementations .
What is a jumbo transport message? Not sure I understand the explanation in .
> The NoiseSocket spec discusses the responder having 5 options based on
> the initial message:
> - Acceptance
> - Change protocol and send fallback message
> - Change protocol and sent reinitialization request
> - Explicit rejection
> - Silent rejection
> I think we can clarify this list, and generalize it a bit:
> - Accept
> - Switch (instead of fallback)
> - Retry (instead of reinitialization request)
> - Explicit reject
> - Silent reject
> This generalizes "fallback" to the responder "switching" protocols and
> sending an initial message - perhaps from a fallback protocol, or some
> other "Bob-initiated" protocol .
I like that "fallback" directly points to what the Noise Protocol
Framework calls "fallback".
> We could rename "Reinitialization" to "Retry" since this is simpler
> language and more aligned with "Retry Request" from TLS.
> negotiation_data noise_message
> Accept *
> Switch * *
> Retry *
> Explicit Reject *
> Silent Reject
Such a table would actually be nice to have in the spec.
> Another issue: Should we allow the NoiseSocket-using application to
> provide some "application prologue" that gets mixed in somehow? One
> option is to simply append an "application prologue" to the above
> NoiseSocket prologues. The above prologues are length-terminated, so
> it will be clear where the NoiseSocket prologue ends and the
> application prologue begins.
Yeah I think it's nice to allow the application to include any
prologue it wants to.
> The current spec emphasizes a message-based API (WriteMessage /
> ReadMessage), instead of a more TCP or TLS-like stream API (Write /
> Read / Flush, something like that).
> The rationale is that you could implement a stream API on top of a
> message API but not vice versa, so this seemed the most general.
> OTOH, a stream API is going to be most useful over TCP, and
> NoiseSocket's length/framing fields are designed for such a case. So
> maybe we'd be better off emphasizing a stream API, here?
Why not having two different APIs for TCP and UDP?
More information about the Noise