[nanomsg] Re: end-to-end security

  • From: Martin Sustrik <sustrik@xxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Wed, 12 Mar 2014 14:41:41 +0100

Hash: SHA1

Hi Alex,

Very good analysis. It nicely demonstrates the point that building
security on SP level is a non-trivial problem.

It may be that we have to step back an look at the problem from 10,000
feet perspective: What is a topology? An interconnected cloud of
clients. What does security mean is such environment? Declining
unauthorised people to access the topology? Something more
fine-grained? Etc.

Btw, your suggestion that REQ/REP scenario is similar to PGP one is an
intrguing one. Can you elaborate?


On 11/03/14 23:45, Alex Elsayed wrote:
> Replies inline
> Drew Crawford wrote:
>> Hello folks,
>> I’ve written before to gauge the interest level on landing
>> encryption support to nanomsg.
>> After my last post, I tentatively decided to go with a
>> libzmq-based solution.  However, for reasons outside the scope of
>> this list, that hasn’t gone as well as I’d liked, and I’m now
>> thinking about nanomsg once again.
>> The problem is important enough that I actually have time to work
>> on it, and due to time constraints I’m going to settle on some
>> solution in the next few days.  The only open question at this
>> point is whether I’m going to land patches in nanomsg, or whether
>> I’m going to be doing some kind of private solution, like a
>> private fork or wrap of some library.  I’d prefer the former if
>> possible.
>> I’d like to make a concrete proposal for comment.  As far as I
>> can tell, there hasn’t been further discussion on the subject of
>> encryption since my last post.  Here is what I’m thinking on
>> design decisions:
>> End-to-end, “well-above-transport-layer” security.  Don’t get me
>> wrong, there is a good case for transport-layer security.  Zeromq
>> has used it with some success.  I use it right now.  The thing
>> is, I’ve become convinced it’s the wrong approach for **my** set
>> of problems.
> Alright, that's a fair enough thing to say...
>> Zeromq's support gets poor when you move out of TCP transport.
> ...but this implies to me that you are conflating a poor
> implementation with a poor approach.
> TLS works over any reliable in-order stream - if you have AF_UNIX 
> SOCK_STREAM, then you have something TLS can be run over.
> DTLS works over any bidirectional datagram transport (and there are
> ways to make it work for unidirectional cases) - thus you can use
> In both cases, you just need to let the TLS library know how to
> send the data. Some make this easier than others; OpenSSL in
> particular is sadly burdened with a rather poor API. GnuTLS is
> nicer in various ways, but uses a license that makes it unlikely to
> be the first (or possibly even _a_) choice for nanomsg.
>> It would be a lot of work for them to support IPC, for example,
>> which I’m mildly interested in. I suspect that UDP is somewhat
>> challenging as well, which is a long-term goal.
> If that's the case, then the issue is a poor implementation in ZMQ.
> Not a limitation of TLS/DTLS - see above.
>> Doing security work near the surface means it’s completely
>> decoupled from adding new transports, which is good if you want 
>> new transports, and also good if you want security to work with
>> them.
> Agreed, and doing security at the transport layer means it's
> decoupled from new SPs, and the same arguments apply. That's the
> reason I feel that _both_ should be implemented sooner or later.
>> Patches to the cryptography require deep knowledge of zeromq
>> internals, and the people with the right knowledge are often
>> busy.
> Patches to any cryptography require deep knowledge of the many
> pitfalls, and the people with the right knowledge are quite
> uncommon overall. It's the main reason that sticking with tested,
> well-known systems is so critical - changes that _seem_ small and
> inconsequential have time-and-again resulted in complete
> invalidation of the assumptions that the security of a system 
> relies on.
>> When minor features to security are needed it creates major
>> delays.
> ...which, IMO, are better than minor changes to security leading to
> major losses of security.
>> If security sits near the surface it requires knowledge of mostly
>> public APIs and so cryptography work can proceed without
>> scheduling meetings with core committers to understand the
>> obscure internal design of the day.
> "Obscure internal design of the day" was one of the problems with
> ZMQ that inspired the creation of nanomsg in the first place - it's
> explicitly designed to be componentized, such that this kind of
> work _isn't_ arcane deep magic.
>> Focus on REQ/REP, and maybe DEVICE, which are the sockets I’m
>> interested in.
> The problem is that REQ/REP has some very hostile semantics when 
> implementing encryption atop it. Incomplete list:
> - Requires 0-RTT key exchange (means forward secrecy is
> impossible) - Cannot assume two REQs go to the same endpoint. Thus,
> every single REQ must contain entire key exchange data (REP,
> however, may potentially reuse state in some cases. Requires
> study). This bloats small requests enormously.
>> The other socket types can wait until somebody is sufficiently 
>> motivated to make security work for those socket types.
> Wholly agreed there. Transport security is per-transport, SP
> security is per-SP. Because of the wide variance in semantics
> between SPs, it's incredibly unlikely they can all provide the same
> security guarantees, much less use the same protocols.
>> Stick close to CurveCP where sensible, but allow for some
>> experimentation. Maybe the user can choose from several competing
>> security mechanisms.
> CurveCP will not work here. First of all, it's not 0-RTT. If you
> require a REQ/REP for key exchange before the data, your system is
> broken due to endpoint load-balancing. You need to bundle key data
> with your outgoing REQ, or at least sufficient identifiers for it
> to be looked up out-of-band (say, via the management interface).
> REP must do the same. The result looks more like OpenPGP than
> CurveCP - in fact, OpenPGP would work without any changes. Pity
> about the message inflation.
> In addition, you have the problem of key management. If you have a
> load- balanced set of REQ/REP endpoints, then do they all have the
> same key? If yes, that's a problem because you can't cut one out in
> the case of compromise etc. If no, you can't control which one the
> REQ gets routed to, and thus the sender must encrypt it to _every_
> potential recipient, resulting in a major amplification of both
> compute time and message size.
> I have yet to see someone suggest doing encryption over REQ/REP
> without completely ignoring the fundamental part of REQ/REP where
> it says that there are no guarantees of endpoint continuity between
> two REQs.
> If that is ignored it's easy! It's also wrong, broken, and
> insecure.
> <implementation details snipped>

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


Other related posts: