[noise] Potential redesign?

[Daniel Kahn Gillmor]

On Tue 2015-03-17 13:50:00 -0400, Stephen Touset wrote:
> I’m a little conflicted on the other hand. I like the idea from a
> technical perspective, but this also increases complexity. We can
> specify up-front one or more protocols built from these primitives
> that are recommended for people to use, but that (perhaps unfairly)
> reminds me of SAML-fueled nightmares. One thing that appealed to me
> very strongly about the original Noise protocol was the fundamental
> simplicity. Having a bunch of primitives that can be composed into a
> few solid protocols is great, but I worry it means we have a bunch of
> primitives that can also be composed into countless terrible
> protocols.

I totally get the sentiment Stephen is expressing here: we have a
history of making very clever toolkits which contain lots of different
choices of tools, most of which have very rough edges, and users end up
just trying to not hurt themselves.

otoh, maybe we need to think about things as toolkits at different
levels, so that the choices we expose to each toolkit user are
appropriate for their task.

If we can come up with a clear, comprehensible taxonomy of the features
each particular recipe/combination provides to users, then users can
consult the checklist/table, and say something like "hm, i'm looking to
do stream-based key establishment, and i care about 'Forward Secrecy'
and about 'Server Identity Hiding', but not 'Client Authentication', so
i should choose HandshakeNX".  (it looks like all the combos Trevor has
listed have forward secrecy, but i suppose given the primitives
available, we can come up with some that don't have forward secrecy
too).

Maybe this kind of taxonomy is a pipedream?  or maybe the hope that
protocol designers will think carefully enough to consult it effectively
is a pipedream?  But i'd like to think it could be a useful
contribution.

   --dkg