[nanomsg] Re: How is security going to be implemented in nanomsg?

  • From: Garrett D'Amore <garrett@xxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Mon, 16 Jun 2014 19:30:04 -0400

There is a fallacy here.  That is that it is even possible to have a solution 
that applies to nanomsg as a whole that even CAN be suitable for deployment on 
the wider internet. 

It is possible to do this for large classes of applications using existing 
infrastructure for PKI.  But there is NO such thing as a single solution that 
is remotely general. 

There are too many challenges.  You can implement a secure general purpose 
solution if you are willing to deal with certificate management. But huge 
numbers of applications have indicated that the overhead of managing a full PKI 
for every client is simply too onerous. 

I agree with them.  

Don't look to nanomsg as one size fits all.  If you want to secure your app 
then you MUST understand both the security needs of your app including threat 
assessment and the level of administrative overhead you can tolerate AND you 
need to have a basic understanding of security.  

Hire some one who can help you if you can't do it yourself.  Do not just try to 
solve it yourself.  The road is littered with the bodies of others who have 
tried and failed.  (Recall WEP?)

Failing that require something like IPSec and let your VPN and network people 
solve this for you. I guess that is till just hiring security experts in a 
different way...

Sent from my iPhone

> On Jun 16, 2014, at 1:01 AM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
> 
> I agree with the sentiment that this is hard and will require original 
> research.
> 
> However I think Andrew is right to raise the product question.  You are not 
> doing any internet-scale networking in 2014 without a solid security 
> strategy.  The question before us is effectively whether nanomsg is to be 
> used across the internet or no.  
> 
> I would argue that based on the things that are commonly said about nanomsg, 
> many people want the answer to be yes:
> 
> “ZeroMQ done right” - ZeroMQ is increasingly used on the open internet, with 
> authentication even
> “nextgen BSD sockets” - certainly sockets are designed for internet-use and 
> are securable
> 
> As long as there is no particular plan to secure it, I think we should admit 
> to ourselves that nanomsg cannot be either of those things.  It is a 
> messaging library for IPC or your datacenter, and a damn good one, but that’s 
> all.  
> 
> Sure, solving the problems that are necessary to deploy this on the internet 
> is hard, but being hard is an implementation detail.  A user who wants to 
> roll out nanomsg for internet communication is not going to say “Well, I 
> would *like* security, but I understand it’s too hard for them to implement, 
> so I will settle for plaintext.”  Instead they will go use some project that 
> is actually suitable for use on the internet.
> 
> But being hard is not even the hardest problem.  There are people who are 
> willing to work on it, and who are working on it—I am among them.  The 
> hardest problem is that we have to be willing to settle for less than ideal.  
> The solution, should it come, will not be in the form of 48 implementations 
> for 6 protocols * 4 network types * 2 views on NIST.  The solution will be 
> one implementation for one protocol, certain types of usages only.  Just 
> getting that far, as a few people have done already, is a tremendous feat of 
> engineering.
> 
> But when you look at previous threads on this topic, you see pretty clearly 
> that we’re not willing to settle for this.  We want either a perfect solution 
> that works in a substantially high number of cases, or nothing.  By holding 
> this view, we implicitly choose nothing.  After all, few will be motivated to 
> invest the tremendous time and effort it takes to create the first imperfect 
> solutions, if we have already rendered our verdict that limited solutions are 
> of such little value that they are not even worth accepting as contributions.
> 
> As long as these set of facts are true, it is time to get realistic about 
> what we are doing.  This is a messaging library for use on your private 
> network.  It’s not a general-purpose internet communications library.  By our 
> actions, we prioritize things that are useful for messaging on a private 
> network over things are are useful for internet communication.  With each new 
> plaintext protocol, we increase the difficulty setting for securing nanomsg 
> as a whole.  When you take the limit of the current trajectory, you get a 
> fantastic messaging library.  But you don’t get a library that is suitable 
> for deployment on the naked Internet.
> 
> Drew
> 
> 
> 
>> On Jun 15, 2014, at 4:35 PM, Alex Elsayed <eternaleye@xxxxxxxxx> wrote:
>> 
>> 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: