-----BEGIN PGP SIGNED MESSAGE----- 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? Martin 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 > UDP, AF_UNIX SOCK_DGRAM, or AF_UNIX SOCK_SEQPACKET. > > 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> > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTIGQVAAoJENTpVjxCNN9YCYcIAK014C7wWH+Ud0EjatLQORNP j0QZWVoFg53RAnGfPYSFu3bDeoPCnVzQC7XhxEm/le/pdP5hTZ5vAvtishVkZZFd t6Yr/ZaeCsD0cRf3SgI2B+ziCB32UlNtrBVAylRtyG/h0H3Y+DzOGu6yA/LQ5Z3g 1PSJwPhLZdcy8meTjhWMsAoKO2QhlnAz8EW2lTQzQUNLSZKVMwTW/fuwZrnvSBMH vCwL+Bl6hWbMV/eSO88cK6PMyAMlUnCBu6pu0brIE1zNkuBHCLQ4zKS5ufUG2y1k v7PPokkGLgLwORb2Zrcp/DhmpwqjNfJoCW3X2Vq8AwmBH3QAuqeYS+3YKDA+JOY= =N6sT -----END PGP SIGNATURE-----