[zeromq-dev] CurveZMQ comments

[Pieter Hintjens]

On Wed, Sep 25, 2013 at 1:04 AM, Trevor Perrin <trevp at trevp.net> wrote:

> 1) Since it's running over TCP (not UDP), are the "anti-amplication
> padding" and "cookie" from CurveCP still needed?

You can do amplification attacks over TCP, and the cookie reduces the
state the server has to hold for unknown clients.  The cookiie
mechanism might be simplified but at this stage I don't see a problem
with sticking closely to CurveCP where possible.

> 2) Assuming the exchange of messages happens over an in-order
> transport like TCP, would it be possible to "rekey" for forward
> secrecy as messages are exchanged, so a key compromise at time T would
> not affect earlier data?  (See discussion of such mechanisms here
> [1]).

Presumably, yes. Are you volunteering to do the design work? :)

> 3) If the client doesn't already have the server's public key, it
> would presumably need to retrieve it, which would add a 3rd round-trip
> to the CurveZMQ handshake before data could be sent, on top of the TCP
> handshake.  That's a lot of latency, would you consider alternatives
> like:
>  - Allowing the server's long-term key to be sent in the WELCOME command
>  - Allowing sending of client data in the INITIATE command

The client can send data immediately after sending INITIATE, without
waiting for a reply. It just sends INITIATE and then MESSAGE. There's
no benefit in extending INITIATE with message data, and it makes the
protocol and codec more complex (two different commands sending data).

Why would sending the server key in WELCOME help? The client already
needs that to send a valid HELLO.

The client would indeed need a separate exchange to get the server
key. Perhaps from an address server, for instance. However it would do
that one time, ever, not on every connection. So doing that lookup
would not add latency to a connection.

> 4) While the modifications to the CurveCP key agreement seem to fix
> the known security problems, the key agreement still seems a bit
> complicated, and I'm not aware of any security proofs for it.

Sure. Sticking close to CurveCP means that as more people use that,
and critique it, we benefit.

> I've been advocating "triple diffie-hellman" in this scenario, as it's
> simpler, more bandwidth-efficient, and has some formal security
> analysis [2,3,4].  Adapted here, that might look like...

If you have alternative security mechanisms to propose, that's
excellent. You may want to read http://hintjens.com/blog:45.

Concretely, for a new security mechanism for ZeroMQ, we need to:

* write an RFC (use http://rfc.zeromq.org/spec:24 as a basis, perhaps)
* write a reference codec
* write a mechanism in libzmq.
* build the API for clients and servers to use that.

-Pieter