[nanomsg] Re: How is security going to be implemented in nanomsg?
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sun, 15 Jun 2014 09:02:26 -0500
ZeroMQ auth works well for a certain class of applications. I’m sort of
winging this off the top of my head, but the list looks like:
People who are willing to use a non-standard thing
People who are willing to use things that aren’t NIST-approved
People who are willing to use things that have not been formally audited
People who are satisfied that elliptical curve cryptography is good
People who trust Daniel Bernstein
People who are willing to pre-share keys
People who are satisfied with a one-to-many client-server relationship
People who don’t have unusual performance requirements, or are satisfied with a
solution that’s vaguely TLS-speed
People who are satisfied to use a security system without a formal support
relationship with the vendor
People who are satisfied to use a security system without any established
security response process
I personally have concerns about certain design details of ZeroMQ’s
authentication scheme that I would want to investigate before I used it. It’s
possible these could be nothing, but I would want to check them out.
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.
Drew
On Jun 15, 2014, at 8:45 AM, crocket <crockabiscuit@xxxxxxxxx> wrote:
> 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:
