[noise] expected length of messages during handshake

[Trevor Perrin]

On Fri, Nov 3, 2017 at 1:16 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>> We're using the term "application" here to mean the entire context
>> Noise is used within, not just the payloads.
>
> I see, this makes it harder to have Noise as a pure library to be used
> as a secure layer in between the application and the transport.
> My implementation can be used exactly like you use TLS in Go (cf.
> https://github.com/mimoo/NoiseGo/tree/master/readable )

If you want a drop-in replacement for TLS, you need to decide several things:

 * Which crypto algorithms to support

 * Which pattern(s) to support (server auth and/or client auth?
identity hiding?  pre-knowledge of keys?)

 * If/how to do padding for length-hiding

 * If/how to do negotiation of "ciphersuites"

 * If/how to handle protocol upgrades

 * If/how to do resumption and/or 0-RTT

 * Whether to build your protocol with a "stream" API or a "message"
API (i.e. do Noise transport message boundaries have meaning to the
application, or are they just fragments of a stream)?

Adding a length field is going to be an easy - almost trivial - task,
compared to above.

I do think there should be answers to those questions in the form of
"higher-level" protocols like NoiseSocket (or Wireguard, Lightning,
etc, for different use cases).

But I think those are best defined in separate documents that build on
the Noise core spec.


>>> I'd say the use cases where you already have a framing for Noise are
>>> small enough for us to add a relevant overhead of 2 bytes per messages
>>> in the spec.
>>> I think a more clever approach would be to have the possibility to
>>> remove the 2-byte header in "advanced usages" for such scenarios.
>>
>> That ends up at the same place, doesn't it?  We either say:
>>  * This isn't part of the Noise message but you can optionally add it, or
>>  * This is part of the Noise message but you can optionally remove it
>>
>> The first option seems better because it doesn't create ambiguity
>> about what is the Noise message and what isn't.
>>
>
> Totally! I guess my point is that I'm arguing for option 1 because:
>
> * it makes Noise work without a framing protocol underneath it
> * it makes any implementation of Noise interoperable without something
> like NoiseSocket
>
> about ambiguity, you could keep Noise messages and have a 2-byte
> length header + Noise message = Noise frame
> or find something along the lines.

Sure, that's definining another protocol layer which adds framing
fields before the Noise message.  That's how I'd like to handle this,
and it's what NoiseSocket does.


>> It also matches how we've explained this for years.  We shouldn't
>> change things like this without a strong reason, IMO.
>
> Agree. That's the tricky part, in my opinion it's a strong reason but
> I'll let you decide.

I'm in favor of leaving Noise messages - and the spec - as they've
been, and defining higher-level protocols that build on it in separate
documents.


> Thinking about adoption: having libraries in different languages is
> probably one of the top priority for Noise. If tomorrow someone wants
> to be able to have some of his device run Noise in C to communicate
> with his/her servers in Go, then he/she should be able to just pick up
> libraries in both languages and have them communicate seamlessly.

It's not seamless, due to the questions above.  What pattern(s) do you
use?  What crypto do you support?  How do you negotiate?  Etc...


> Are
> you saying that people should focus their effort on publishing open
> source libraries for things like Noise Socket instead? This would make
> my library obsolete :>

Noise implementations are of course needed for any higher-level
protocols built on it.

But if you're implementing Wireguard you need to implement
Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s *plus* Wireguard-specific stuff.
Similar will be true for NoiseSocket, Lightning, or anything else.

Anyways, I support your goal of having easy-to-use Noise-based
protocols that regular developers can incorporate without too much
effort.  However I think the Noise core spec does not serve this
audience directly - instead, it's targeted at someone designing such
protocols.

Someone who can make it through our spec (50 pages!  abstract
patterns!  complicated security properties!) is not going to have
trouble adding a length field and remembering to authenticate static
public keys...

So we have more work to do, but as protocol designers I think we
should be focusing on extension documents and uses of Noise, rather
than thinking we can make the core spec and protocol serve all use
cases in itself.

Trevor