[noise] Notes and thoughts from RWC2017

[Trevor Perrin]

We had a quick lunchtime meeting with a good set of people (~10),
thanks to Alex for motivating it.

My main question was how to get more users.  I brought up new
protocols like "DPRIVE" (DNS privacy) and NTPsec, and asked why
they're looking at TLS/DTLS and not Noise.

Dkg argued that application-protocol designers want to plug-in
something with an easy high-level API, they don't want to build their
own crypto out of patterns.  Our current spec is useful to crypto
people, but not to application designers.

I think he's right, and that points towards new work (more below).

---

On the post-quantum front, there was talk about something emerging
that might be similar to NewHope but better.  So even for experimental
work, we should probably wait a few more weeks.

---

Mike Hamburg presented STROBE, a protocol framework centered on sponge
functions.

https://eprint.iacr.org/2017/003

Aside from the focus on sponges rather than AEAD and hashes, I think
of this as similar to Noise's SymmetricState but more flexible, so it
can be used for a wider range of protocols.  It would be interesting
to try specifying SymmetricState using STROBE, to give a Noise/STROBE
combination.

---

Thinking about concrete / higher-level protocols:

Noise started with concrete designs for "Box" and "Pipe" protocols,
with Pipes built out of Boxes.  At some point we realized these, and
other things, could be expressed with a general "pattern" language, so
we turned towards abstraction.

That's worked well in that we have a flexible core language that can
describe a lot of protocols, and can be easily extended.

But it didn't give us something easy to use:  (A) the patterns are
abstract and hard for non-crypto people to understand.  (B) Even when
instantiated, Noise only gives you a minimal core where the user has
to fill in details around framing, padding, versioning, etc.

So we should probably work towards a few higher-level protocols that
give easy entry points into Noise (Scratch's recent work on a
"NoiseTLS" is exactly this direction).

I'm thinking about maybe a "NoiseSocket" and "NoiseBox /
NoiseMultiBox", but I'll kick off some other threads to consider this.


Trevor