[zeromq-dev] CurveZMQ Enhancements

[Pieter Hintjens]

On Wed, Oct 1, 2014 at 7:21 PM, Matthew Hawn <matthewh at donaanacounty.org> wrote:

> Message Size Limits
> It behooves a pubic server to not accept large messages until authentication
> happens.

Good idea. Does not affect the protocols afaics, it's an
implementation concern. Can be done in the curve client/server.

> Memory Usage
> There is currently several large buffers that are only used during
> handshakes but kept for the whole session.

An implementation concern.

> Zero State Initial Connections
> The protocol enables the server to keep zero state until the client has
> authenticated.  This would allow public servers to mitigate DOS attacks much
> more effectively.  However, implementing this would require DEEP changes in
> ZMQ: socket, session, stream_engine, mechanism, and so forth.

Ditto, right?

> Invalid Message Handling
> After the  handshake is completed, it seems to make sense to drop invalid
> messages rather than killing the entire connection.

Ditto, though I think invalid messages = invalid client = kill it with fire.

> Message Command
> Currently, after the handshake, CurveZMQ sends messages back and forth
> prefixed with a "\7MESSAGE".   Do we really need to have this for EVERY
> message?

Shrug. We could reduce this to 2 bytes. Is this worth it? Arguable,
given the CPU cost of handling CURVE traffic.

> Certificate Exchange
> It would be nice to have a protocol level mechanism for exchanging
> certificates before authentication.

Yes, but cannot be done in ZMTP. Requires (afaik) an out-of-band
bootstrap over some existing secure transport, to avoid MIM attacks.
So not a CurveZMQ issue. I realize this is a cheap answer.

> This is not about certificate format or
> validation mechanisms, just a way to exchange the cert blobs and call on the
> application to do validation. I am currently working on a proof-of-concept
> and will share more with the group later.

I'm curious how you avoid MIM substituting its own permanent keys for
the ones you are trying to exchange.

> Crypto Library

Agreed, not a protocol concern though. Feel free to push tweetnacl
into the limelight.

-Pieter