[noise] NoiseSocket status and plans

[David Wong]

Hey!

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 [1].  This might
> improve efficiency for high-speed implementations [2].

What is a jumbo transport message? Not sure I understand the explanation in [1].


> Negotiation
> ------------
> 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 [3].

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.

Agree.


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


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

David