[zeromq-dev] EncryptedSocket added to pyzmq in branch

[Martin Lucina]

Hi all,

coming a bit late to this thread, thank you all for the many interesting
points and discussion.

"Security" is a very vague topic, and as others have pointed out different
people have different needs in terms of trust and the risk factors they are
trying to protect against.

As I see it, there are two separate parts to "Security" in 0MQ.

1) Robustness. This is a work in progress, with the competition Pieter
already mentioned, personally I would also like to spend time
systematically hardening 0MQ to follow the well accepted principle of "Be
liberal in what you receive, and conservative in what you send."

0MQ should be robust enough that it cannot simply be crashed remotely.
Obviously if the *application* using 0MQ is not robust against invalid data
then it may not survive an attack, but that is outside of our scope.

Further, 0MQ should provide enough hooks and sensible defaults to minimise
the chance of a remote DoS. For example, at the moment if you decide to
send a 4GB message, the receiving peer will gobble it all up happily, and
possibly go off and thrash for a while. So what is needed is a sane default
for "maximum message size", and a mechanism for the application to
manipulate this default, detect/block/unblock rogue clients for
administrative purposes, and so on and so on.

This is just an example; there are many cases like this in 0MQ. Some are
easier to solve than others. So, it's a work in progress, and we'll get
there, eventually, with the help of the community.

2) Encryption and/or authentication. Min's work here is a nice experiment,
and it gives us excellent discussion points, so I'll react to those here:

> 1.  Is the EncryptedSocket interface that Min has prototyped in his
> branch a good plugin interface for users to add message based
> encryption of their choice.

It's a start. I take it you're explicitly not caring about key management,
which is a complex problem all on its own.

> I think that once everyone understood that Min's prototype leaves the
> choice of cryptographic approach up the user, they became more
> comfortable with the design.  It does not pick or enforce a particular
> encryption approach.  But, one valid point made is that the interface
> does not force users of pyzmq to handle encryption in a correct
> manner.  They might do it well, or they might do something very
> insecure.  This is important...

Precisely, Burak has made good points about this. Naive users may use bad
crypto, and rely on it. This is why we have TLS, IPSec, and so on. Just
plugging a cipher on top of 0MQ doesn't constitute good design.

> 2.  Is the idea of message based security worth pursuing?
> 
> I think Min's recent email summarizes the differences between message
> based and transport based security:
> 
> Transport: encrypt/decrypt happen at each zmq hop
> Message: only decrypt at endpoints (big deal for many relay hops)
> Transport: always encrypt everything
> Message: can encrypt only the sensitive subset of traffic

In my opinion, and looking at it from the point of view of eventually
arriving at a solution which we could implement as an (optional) part of
the 0MQ core, message-based encryption is the only way that makes sense.
It allows for sensible multihop topologies, and is the only sane way of
dealing with encrypted multicast.

> 3.  What type of cryptographic approach is appropriate for message
> based security.

I would look at prior art here. If we're dealing with message-based
encryption, then the existing model that would make most sense is something
like the IPSec ESP (provides encryption) and AH (provides authenticity)
layers.

Steve McCoy also mentioned DTLS at some stage; I have no experience with
it, maybe someone here can say if it's worth looking at.

> What vulnerabilities remain if message based HMAC + AES security is
> used?  In my mind, the main issue become how to distribute/exchange
> keys.

Key management, definitely. However, that can be factored out as a separate
protocol and an application, much the same way as IPSec does it with IKE.

So the only functionality 0MQ core would provide would be per-message
encryption and decryption, with a well-defined wire protocol to support
this, and leave it up to the user to provide the keys.

As a 2nd step, a scheme similar to IKE could be designed, which would run
as an application on top of 0MQ.

Cheers,

-mato