[zeromq-dev] Topics for ZMTP 3.0

[Ciprian Dorin Craciun]

On Thu, Jun 6, 2013 at 3:09 PM, Pieter Hintjens <ph at imatix.com> wrote:
> The current draft is here: http://rfc.zeromq.org/spec:23, and libzmq
> already implements most of that (NULL and PLAIN mechanisms). We just
> merged a patch from Martin Hurton to do ZAP authentication
> (http://rfc.zeromq.org/spec:27).


    I've quickly looked through the ZAP specification (27), and at a
first glance I have the following observations:


    (A.1) The specification refers to strings, but doesn't impose any
constraints (i.e. encoding) on them:  are they ASCII only?  are they
UTF-8?  what is the maximum allowed length?  For that matter some
sensible maximum lengths should be imposed for all the fragments
(think of how many buffer overflow bugs there are out there...)

    (A.2) The specification also says that there should be an integer
to identify the session, that shouldn't be interpreted by the handler.
 Why can't it just be an arbitrary blob, where the server can store
anything it wants (within a sensible amount), thus allowing truly
stateless authentication on part of the server.

    (A.3) The specification says that the method specific data is only
one fragment.  Why shouldn't the specification allow any number of
fragments, and then each method limiting how many fragments it needs.
Thus for example in the PLAIN method, the first fragment would be the
user-name and the next the password.


    (B) For the PLAIN authentication, why not use **only** an ASCII
based payload, given that the rest of the protocol is already ASCII
only?

    For example instead of encoding "one byte length, that many bytes,
one byte length, that many bytes", it could be "length as ASCII
integer followed by `:` followed by as many bytes as length specifies,
followed by space ` `, and again length, `:`, string" (or something
similar like this that can be parsed by using only strings).

    See also the string encoding observation above, and the
multi-fragment solution.


    (C) Instead of (or before the) CURVE mechanism --- which I find
very underspecified, mainly because I know nothing of CURVE --- maybe
a method like DIGEST would prove more useful, being a middle ground
between plain-text and fully cryptographic.


    (D) I think there should be a way to obtain mutual authentication,
where also the client is able to authenticate the server.


    (E) What is the difference between it and SASL?  Or better said
why can't we rely on SASL, and provide a SASL adaptation on-top of
ZeroMQ, thus we could re-use a lot of existing solutions.  (I'm aware
that one could easily invent new methods and delegate them to a SASL
backend.)


    I hope nobody interprets the above as "bashing" on ZAP, it's a
good start in having a common protocol over ZeroMQ, I just think that
it should offer more "out-of-the-box".

    Ciprian.