[noise] Notes and thoughts from RWC2017
trevp at trevp.net
Sun Jan 15 10:47:35 PST 2017
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
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
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.
More information about the Noise