[nanomsg] Re: end-to-end security
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 12 Mar 2014 14:41:41 +0100
-----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-----
Other related posts:
