[nanomsg] Re: How is security going to be implemented in nanomsg?
- From: crocket <crockabiscuit@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 15 Jun 2014 22:45:53 +0900
I'm just an ordinary grunt like everybody, and I'm dumbfounded at the
complexity.
To make things easier to understand, I want to ask a question.
How do you think about ZeroMQ authentication? How do you compare it with
your ideas?
On Jun 15, 2014 12:24 PM, "Drew Crawford" <drew@xxxxxxxxxxxxxxxxxx> wrote:
> 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:
