[zeromq-dev] Topics for ZMTP 3.0

[Pieter Hintjens]

On Fri, Jun 7, 2013 at 1:56 PM, Ciprian Dorin Craciun
<ciprian.craciun at gmail.com> wrote:

>     (A) As mechanism is specified, interleaving `%x0` characters are
> allowed in between the other characters

Not sure what the correct grammar would be, so it's specified in the
text as "Mechanism names SHALL consist only of uppercase letters A to
Z, digits, and embedded hyphens or underscores."

>     (B) From how the `command-size` and `message-more` are specified I
> deduce that just by looking at the traffic I can detect when the
> connection has changed from "command" mode to "message" mode

Yes, the command bit is explicit. I'm not sure we will literally
switch modes. I'm thinking e.g. of heartbeat commands which would mix
with messages. Certainly in clear text connections it will be easy to
separate commands from messages.

>     The same observation can be made for all the cases.  Moreover the
> reconnection handling seems a little bit fuzzy to me (at a first
> glance), some cases allowing reconnect, some not, and in all cases you
> can't deduce what has actually happened with the other peer.  Maybe
> all cases should be handled with an exponential backoff approach.

Could be. I'm not sure what the best approach is here. The goal was to
detect failed authentication as different crashed peer, without any
explicit error code in the first case (I want the server to simply
drop connections from invalid clients). In the former, clients don't
want to reconnect, but in the latter they do. In practice it's no more
than a hint.

It might turn out that an explicit "rejected" response is better than
cutting the connection.

Over clear text, there are so many attack possibilities I think we
have to assume that'll only be used in constrained environments.

>     (D) In the case of an "encrypted" connection, the specification
> says that the messages are "wrapped" in commands.  This means that an
> attacker can identify how many messages, and how large, each peer has
> exchanged.

Yes, indeed. However this can be masked by the mechanism, e.g.
resizing messages, adding fake ones, etc.

>     I guess that the reason is the following: once the peer selects a
> "mechanism" then both the authentication and the privacy is completely
> delegated to that mechanism, thus obtaining an almost "perfect"
> decoupling between transport, framing and security.

Yes. This is the goal. We can't make perfect security (CurveZMQ is
more of a question than an answer) but we can make it cheap for
cryptographers to get involved.

>     Maybe the "safest" solution is to require the following:
>     * completely specify (in the ZMTP specification) a few transport
> security mechanisms; (just for example like: use RC4, or use AES 128
> in CTR mode, etc.;)

We can certainly add some conventional mechanisms. The reason for
choosing CurveCP as the starting point was to not claim that space.
People have already discussed a DTLS mechanism which seems ideal.

>     * the security handler should then be able to choose one of the
> available mechanisms, and also provide the "arguments" (i.e.
> cryptographic material) needed to configure them;

Right, we've started to add this into the libzmq API.

>     (E.1) I find it odd that the "connection meta-data" is a
> by-product of the security, thus reducing the reuse potential of the
> ZAP protocol.

True. It seems wise to not send any meta-data until after
authentication, to reduce the information one can gain by probing a
system. What I expect is that we'll expand ZAP with meta-data to send
back to the peer after successful authentication.

Meta-data has to be encrypted by the mechanism (if it encrypts), but
the three mechanisms so far use the same format for meta-data (a
key/value table).

>     (E.2) Shouldn't the "identity" be mandatory?

It's optional for sockets that talk to ROUTER sockets, and not used on
other sockets.

>     (F) As an observation, I've once read the specification for SOAP,
> and found a very nice feature that I've failed to see in other
> "transport" mechanisms: mandatory vs optional envelope elements (I
> think "elements" were called?).  For example we could say something
> like this in ZMTP:  all commands have a "mandatory" flag, that if
> present the other peer must either understand them or fail;  if not
> mandatory they can be ignored, but replied back as not-understood.

I'd have to see what problem this solves in ZMTP; the goal above all
is to keep this simple.

>     (G) For the purpose of replying back if a command is not
> understood, or for asynchronous parallel commands, wouldn't it be
> better if all the commands are identified with a unique identifier
> chosen by the sender?

We're very far from needing this level of dialog. E.g. for CurveZMQ:

curvezmq = C:hello S:welcome C:initiate S:ready *message

ZAP needs it so the caller can re-route replies correctly.

>     Moreover couldn't we allow commands to be interleaved with
> messages, thus opening a door to something like flow-control, etc.
> (But these features shouldn't be missuses.) :)

The spec does disallow commands mixed with messages, but I'm going to
change that to add heartbeating, experimentally.

>     (H) In general when it comes to "hard-coded" tokens like socket
> types or security mechanisms, I think there should be a prefix that
> denotes "experimental" or "private", just like in case of
> `X-Something` HTTP or SMTP headers.

Indeed. I'll add that.

>     As a general remark, I think ZMTP is still balanced in terms of
> complexity and what it offers.  Good work!

Thanks for the feedback. If you don't mind I'll add you to the list of
contributors to ZMTP.

-Pieter