[noise] Comments on the specification

[Trevor Perrin]

On Sat, Apr 9, 2016 at 5:25 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> A few minor comments as I've been working on Noise-C.

Hi Rhys,

Nice start on the C lib, good name.

Definitely send any feedback or unclear parts you find in the spec,
feedback from implementers is gold at this point.


> Under section 12, "Application Responsibilities", it is mentioned that
> length fields can be up to 65535 bytes and a 16-bit big-endian packet length
> field should be prepended.

The prepended type+length fields are just a recommendation.  I.e. if
you need some framing and don't have a strong reason to do something
else, you might as well do that, it's a reasonable choice and might
lead to some interop.


> Which is fine ... except that won't always work in the embedded space.
> Systems I use regularly have 8K, 20K, or 96K RAM sizes.  So a full Noise
> packet at maximum length either won't fit, or it will use so much RAM that
> there's nothing left over for the application.
[...]
> The sending side is not a hassle.  It's the receiving side where the other
> party can send requests that are too big to be processed.  I suggest adding
> some text to section 12 indicating that applications may need to negotiate
> the maximum packet length that a receiver is willing to accept.

Good observation.  It would be fine if an application using Noise adds
a tighter constraint on message sizes.  Given a Noise API, that can be
implemented by the application just sending smaller payloads.

So I'm not sure we need to treat this in the spec, or that library
developers need to do anything specific for it?


> On the subject of "Application Responsibilities" again, there are a lot of
> good recommendations there.  I would like to see "reference protocols" for
> UDP and TCP transports, and for one-way offline traffic (e.g. file
> encryption).
>
> If the application author doesn't have any specific preferences then they
> can use the reference protocol and be reasonably confident that they won't
> make a mistake in padding schemes or whatever.  This may involve defining
> specific type field values, algorithm negotiation prologues, and padding
> schemes.  Separate specification possibly.

Yeah, it would be nice to have some worked-out uses and protocols in public.

Starting with 1-byte type + 2-byte length gives you minimal protocols
for TCP and similar, as a start.

I'll add a recommendation to the spec that the type field's default
value be zero, and explain it's use a little better.  That makes this
concrete enough that people could at least interop over TCP using the
minimal framing:

 * **Type fields**:  Applications are recommended to include a single-byte type
   field prior to each Noise handshake message (and prior to the length field,
   if one is included).  A recommended idiom is for the value zero to indicate
   no change from the current Noise protocol, and for applications to reject
   messages with an unknown value.  This allows future protocol versions to
   specify handshake re-initialization or any other compatibility-breaking
   change (protocol extensions that don't break compatibility can be handled
   within Noise payloads).

Trevor