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

  • From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Sat, 14 Jun 2014 22:23:38 -0500

It’s something of an open secret at this point that I develop a private fork 
that addresses some of the points Alex raises.  His analysis is pretty 
consistent with my experience.

I’d like to inject here a mode of analysis that has been useful to me in the 
last few months of working on this problem: the idea of asymmetric trust.

If you consider the typical web server/browser scenario, the client wants to 
authenticate the server but only in certain cases does the server want to 
authenticate the client.  More fundamentally, a server is trusted with all 
clients’ traffic and trusted not to leak client A’s traffic to client B, but 
clients are trusted only with their own data.  These factors form an asymmetric 
trust model, where the server enjoys a position of more trust than the client.

This asymmetry does not arise from REQ/REP; there are in fact valid REQ/REP use 
cases that would prefer the asymmetry to be different in some way.  For example 
if you are running Folding@Home, it is the requesting client that is trusted, 
and the pool of workers that is untrusted.  That is an unusual case, but there 
is no network-theoretic reason why it is unusual—it’s just that not many people 
try to do this.  But REQ/REP *allows* you to do this, and so shipping a 
web-like security model that is badly broken for Folding@Home seems like a poor 
idea to some.

When you look at the “use TLS at the transport layer hop-by-hop” solution such 
as what you see here 
(https://github.com/nanomsg/nanomsg/blob/master/rfc/sp-tls-mapping-01.txt), you 
see a more symmetric model of trust: neither the REQ nor the REP (nor PUSH, nor 
PULL, etc.) is more trusted than the other.  And so at first glance this looks 
promising.  However the way this works in practice is that a node is either 
allowed on the network or it is not.  If it is, then we trust it not to spoof 
messages from other senders and so on.  This works fine if you are running 
nanomsg in your own datacenter only on your own nodes.  But obviously, no 
system based on this principle can ever work if the nodes are allowed to run on 
other people’s computers.  So this scheme is badly broken for any case where 
you have a distributed network between two or more *people*.

So what we have developed here are three broad categories of problem domains, 
each of which balances trust differently, and prefers a different security 
guarantee:

“Trusted server” networks, like the web
“Trusted client” networks, like Folding@Home
“Trusted everybody” networks, like your datacenter

From this analysis we can predict a fourth type of network—the “trusted nobody” 
network—and we see this idea reflected in e.g. Tor.  So the analysis method is 
robust to a wide variety of different applications.

What this suggests is, at minimum, there are 4 separate analyses and 4 separate 
solutions and 4 separate implementations *per protocol*.   Nanomsg currently 
has 6 protocols, so this is 6*4=24 work.  Now some of these are easier than 
others—for example in the “trusted everybody” scenario, all that is required is 
that TLS is used as a transport.  And, not surprisingly, it is this easy 
solution that has gotten the most support.  But it is still necessary to write 
6 tests and update 6 documentation pages and so on.  

Finally, there is the possibility that requirements could be different *within* 
a network type.  One issue that has come up on these lists is whether NIST 
algorithms are to be used or avoided.  This is a question that potentially 
affects every protocol and every network type.  And, for users who feel 
strongly on this question (as has been demonstrated specifically on these 
lists), it may be necessary to double the work again and produce 24 * 2 = 48 
implementations, 24 following the NIST philosophy and 24 following the 
NIST-avoidance philosophy.

Clearly the only way out of this pit is to find some common elements so that we 
can unify these 4 network types and 6 protocols under a fewer number of 
security implementations.  But, building any of these well requires a great 
deal of cryptographic knowledge, let alone trying to design a common solution 
for several of them.  Knowing what the architecture looks like does not make 
the problem simpler.

My current status is that I’ve developed a very robust and promising solution 
for trusted-server req/rep that I suspect is largely extendable to at least 
several other protocols within the trusted-server model.  Later this year I 
will try to extend it to another protocol within the network type and so that 
project will yield a lot more information about what is possible and what is 
difficult about designing security methods to cover multiple different cases.

Drew
On Jun 14, 2014, at 5:28 PM, Alex Elsayed <eternaleye@xxxxxxxxx> wrote:

> Andrew Starks wrote:
> 
> <snip>
>> In that spirit:
>> 
>> What mechanisms are missing from nanomsg that make it difficult to
>> integrate it into an existing security layer?
>> 
>> If none, or those could be addressed, then I believe that you'd be a
>> tutorial away from something valuable.
>> 
>> -Andrew
> 
> In my opinion, it's less an issue of "What is missing from nanomsg" and more 
> about how nanomsg has very different semantics from what most security 
> layers assume.
> 
> Hop-by-hop, at the transport level (TCP, etc), you really do want to use 
> existing mechanisms like TLS - they layer well. However, they _don't_ 
> provide some of the guarantees people want. While you can use, say, TLS with 
> certificates signed by a common CA in order to ensure that only permitted 
> nodes join (and join in the correct places, via subjectAltName or similar), 
> that gives zero protection against a malicious node hearing things it 
> shouldn't if it DOES somehow join.
> 
> Meanwhile, end-to-end measures - like ensuring that your REQ is only 
> readable by an appropriate REP - fit with existing systems very poorly 
> indeed because each pattern's semantics demand a different form of 
> protection entirely.
> 
> A security layer over PUB/SUB would require something along the lines of 
> broadcast encryption (Blu-ray's AACS is an example of such; cable and 
> satellite TV as well), and can't assume bidirectional communication. 
> PIPELINE has similar restrictions.
> 
> Something over REQ/REP can't assume that any two REQs go to the same 
> destination, and SURVEY similarly has sessions that only last one exchange.
> 
> On BUS patterns, any multi-message exchange between two nodes to set up 
> keying would be incredibly noisy and inefficient.
> 
> PAIR, of course, has similar semantics to what TLS and DTLS need - but it's 
> message-based (ruling out TLS) and supports messages far larger than DTLS 
> can handle.
> 
> Broadcast encryption _might_ be able to be made into a general solution, but 
> that would take some real thought by cryptography experts far more skilled 
> than myself. Broadcast encryption systems frequently have the ability to 
> subset which valid receivers can decrypt - that could be used for things 
> like PUB/SUB topics, etc.
> 
> However, broadcast encryption tends to be pretty focused on cases where keys 
> are _allocated_ from some central point, rather than _generated_ by 
> participants, which may be an administrative complication. It'd also pretty 
> much _require_ hop-to-hop security _in addition_ to such a broadcast-
> encryption-based end-to-end system, to prevent such per-node keys from being 
> snarfed off the link.
> 
> 

Other related posts: