[noise] NoiseSocket status and plans

[Trevor Perrin]

On Tue, Nov 21, 2017 at 11:36 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>
> 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?

That's one way to look at it.


> I had the idea that it was more "plug-and-play" than that.

We're working towards "plug-and-play", in small steps.  See the
NoiseLink mail I sent recently, which would fill in the
negotiation_data.


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

No, the negotiation_data is separate from the noise_message.


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

A Noise transport message > 65535 bytes.


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

I like the more general approach, though we could still talk about
"fallback" as being the main example of the Switch case.


>>                     negotiation_data      noise_message
>> Accept                                         *
>> Switch                     *                   *
>> Retry                      *
>> Explicit Reject            *
>> Silent Reject
>>
>
> Such a table would actually be nice to have in the spec.

Agreed.


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

That's an option, or maybe a well-designed API serves both cases.

Trevor