[noise] Revision 33 draft

[Trevor Perrin]

On Sat, Sep 23, 2017 at 11:42 PM, Trevor Perrin <trevp at trevp.net> wrote:
> One nit in current spec is that pattern names include the "Noise_"
> prefix, i.e. "Noise_XX".
>
> The naming scheme seems easier to describe if we treat the pattern
> names as "XX" and make the "Noise_" prefix a separate thing.

Merged: https://github.com/noiseprotocol/noise_spec/compare/rev33

I'm planning to publish this next Monday Oct 2, feedback welcome till then.


Another question for this revision is whether to allow "jumbo" Noise
messages > 64K.

The arguments for jumbo messages:

 * Performance arguments for high-speed encryption:

https://moderncrypto.org/mail-archive/noise/2017/001220.html
https://moderncrypto.org/mail-archive/noise/2017/001221.html


 * The Panoramix mixnet will use a Noise_XX "wire protocol" for link
encryption between parties.  Each application-layer message is fitted
into a separate Noise transport message, so they found it convenient
to use 1 MB Noise transport messages.

https://moderncrypto.org/mail-archive/messaging/2017/002365.html
https://github.com/Katzenpost/docs/blob/master/specs/wire-protocol.txt


For the Panoramix case, I think this is a matter of libraries
providing message APIs instead of stream APIs (like TCP or TLS).
Seems like we could improve this situation in the libraries, without
needing jumbo messages.

The high-speed performance arguments I'm less sure about.  The
overhead of 64K fragmentation as a percentage of bytes is very small.
But perhaps there are other costs, as mentioned in links above.  It
might be helpful if we could get rough numbers on them.

Anyways, Jumbo messages complicate the security story around data
volumes.  Right now there's an implicit limit of 2^80 bytes encrypted
per key.  If you can use bigger messages do we ask libraries to
enforce that 2^80 limit explicitly?  Do we impose some other limit
they have to enforce?

Given that complication and the possibly small benefits, I feel like
it's easier for the spec to just continue with the 64K limit, and
people who really want to patch a library for bigger messages can
worry about these questions on their own.  But I'm not sure.

Trevor