On Wed, Oct 01, 2014 at 08:36:28PM +0200, Pieter Hintjens wrote:
> On Wed, Oct 1, 2014 at 7:21 PM, Matthew Hawn <matth...@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?
Also does that make sense with TCP/IP? The connection already passed
the tcp handshake and from there on it is statefull. You have kernel
and application resources allocated for the socket. Does the ZMQ/CURVE
state add a significant amount there?
> > 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.
Doesn't this fall into the same category as the idea for the client to
send metadata to the server on connect? That would happen before the
connection is authenticated via ZAP, too.
> > 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.
I think he means to have something like ssh does. When you connect to
an unknown host it exchanges keys, prints the hosts fingerprint and
asks the user to validate before accepting. If you blindly accept the
fingerprint then MIT is totaly possible. But if you are security aware
then you verify the fingerprint over an alternative channel.
> > Crypto Library
>
> Agreed, not a protocol concern though. Feel free to push tweetnacl
> into the limelight.
>
> -Pieter
MfG
Goswin
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
