[noise] NoiseSocket status and plans
trevp at trevp.net
Tue Nov 21 21:53:52 PST 2017
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
>> 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 . This might
>> improve efficiency for high-speed implementations .
> What is a jumbo transport message?
A Noise transport message > 65535 bytes.
>> 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".
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.
>> 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.
More information about the Noise