[nanomsg] Re: How is security going to be implemented in nanomsg?
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 15 Jun 2014 14:35:26 -0700
Andrew Starks wrote:
> On Sun, Jun 15, 2014 at 9:02 AM, Drew Crawford
> <drew@xxxxxxxxxxxxxxxxxx> wrote:
>
>> I'm not saying it's a bad system. The number of applications that fall
>> into this class is pretty broad. But it's not universal, and I would
>> want
>> to poke at it in more detail before I used it. As it stands there are
>> some items in this list that make it less than excellent for my use case.
>
>
> Earlier, I ask my "what mechanisms" question. I am/was asserting that
> "what kind and how much security should be baked into nanomsg" is the
> wrong question. Security is a domain that does not cleanly overlap with
> messaging; especially in a library whose name begins with "nano*".
Oh, I agree - note that the 'transport' level stuff I brought up is
conceptually 'under' nanomsg, while the hypothetical broadcast-encryption
thing or whatever would be 'over' nanomsg.
> I don't know what the correct question is. It might be "what makes
> integrating security protocols / authentication / encryption / etc into an
> architecture that uses nanomsg difficult?"
...and _that_ is exactly what I addressed. A large part of the problem is
that this question is actually _too broad_, because there isn't likely to be
any one thing that will work across all of the messaging patterns.
Rather than asking about "an architecture that uses nanomsg" it's probably
necessary to reason about "an architecture that uses stateless
query/response exchanges" (which REQ/REP is), or "an architecture with
unidirectional one-to-many communication" (which PUB/SUB is).
And it's even more complex than that because...
> I know it's a basic point that doesn't involve any knowledge about network
> / computer security. It doesn't start out as a technology problem. It's a
> product problem.
>
> Is nanomsg a security library? If no, then what specific problems are you
> trying to solve? Since it has to interact with libraries that are about
> security, then what can be done to make nanomsg incredibly simple to
> integrate into an application architecture that needs security, whatever
> that might mean.
...'security' means many, often *incompatible* things.
In some cases, preventing overload attacks takes priority over certain kinds
of confidentiality - that's one of the primary objections to DNSCurve, for
example.
In other cases, you need to ensure perfect forward secrecy - but the best
known algorithms for doing that _require_ a bidirectional exchange to
establish a key (although data can be included on the return trip), which is
impossible in systems like REQ/REP. (Think of it as the key exchange to
protect the REP taking up the _entire_ REQ. Every time. And needing to carry
extra data with the REP itself.)
It's a hard problem that may actually require original research in some
cases.
Other related posts:
