On Wed, Oct 1, 2014 at 7:21 PM, Matthew Hawn <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
