[zeromq-dev] About CURVE and ROUTER sockets

[André Caron]

Ah, indeed, I could use the doubled-up router-dealer part of the Harmony
pattern even with my current design.  Makes sense.

> There's an edge case where a node tries to connect and is rejected as its
peer hasn't yet received a key.

If a peer is rejected by curve authentication, does ZMQ automatic
reconnection still work (and will it successfully connect once the "server"
receives the public key)?

Thanks,

André

On Sun, Jan 18, 2015 at 3:05 PM, Pieter Hintjens <ph at imatix.com> wrote:

> You should not be changing public keys IMO.
>
> It is supported and documented and thus guaranteed, however I believe
> it's a misfeature that solves no real problem and rather, opens the
> door for confusion.
>
> On Sun, Jan 18, 2015 at 8:05 PM, Andre Caron <andre.l.caron at gmail.com>
> wrote:
> > Yes, I understand the web of trust model.  In my case, all (legitimate)
> nodes are controlled by the same organization, so I can afford something
> akin to a CA.  My question stays, how could I adapt the Harmony pattern to
> use curve?
> >
> > And, back to my original question: can I assume that zmq-connect() takes
> a snapshot of the current curve server key option and is not affected by
> updating the option later on?  It currently works, I'm just wondering if
> it's guaranteed as it's not entirely clear from the docs.
> >
> > André
> >
> >> On Jan 18, 2015, at 1:57 PM, Benjamin <benjamin.l.cordes at gmail.com>
> wrote:
> >>
> >> It's a very difficult and deep question, if you're building a true P2P
> >> network. If all peers are equal, nobody has some truth with regards to
> >> the identity of another peer. Say you have the following protocol:
> >> each peer starts announcing the identity of all known peers before
> >> exchange data. One peer Bob says that Alice's pubkey is 123, while
> >> another says its 456. Who is right? Maybe Bob is lying, or Bob is
> >> mistaken about Alice.
> >>
> >> The way cryptography works, is that there is an exchange of keys
> >> through a central system - the Public-key infrastructure (PKI). On a
> >> fundamental level PKI requires central key-exchange. It's an authority
> >> who declares that Alice is indeed Alice. On the Internet that
> >> authority is the Internet Corporation (or other central servers).
> >> Usually when people talk about cryptography they mean this kind of
> >> cryptography.
> >>
> >> An alternative framework is web-of-trust. Alice knows Bob and Bob
> >> knows Charlie, so Alice knows who Charlie is. The problem with this
> >> scheme is that each user, has to maintain a list of peer he trusts and
> >> peers can't talk to peers they did not know before. You can read more
> >> about WoT here: http://en.wikipedia.org/wiki/Web_of_trust
> >>
> >>> On Sun, Jan 18, 2015 at 7:43 PM, André Caron <andre.l.caron at gmail.com>
> wrote:
> >>> I've looked at that already and still prefer the router-router setup
> and
> >>> have a convenient solution for discovery, which I'll get back to
> shortly.
> >>>
> >>> Obviously my immediate curve problem would be solved when using the
> Harmony
> >>> pattern because you always create a new dealer socket for each outbound
> >>> connection.  However, it seems to me like this is a non-starter
> because the
> >>> Harmony pattern doesn't provide for secure exchange of public keys.
> How
> >>> would you prevent untrusted peers from connecting to your nodes?
> >>>
> >>> The problem I'm trying to solve is running an elastic group of nodes
> securly
> >>> over an untrusted network.  My current solution is to use a directory
> >>> service which is known to all nodes prior to joining.  This directory
> >>> service has a well-known endpoint, identity and public key.  To add a
> new
> >>> node on the network, the administrator generates a new keypair,
> registers
> >>> the new public key with the directory service and then starts the new
> node,
> >>> which can then connect to the directory and discover other nodes.
> Since
> >>> each node has a secure connection with the directory, it can discover
> the
> >>> endpoint, identity and public key for each peer it wants to connect to.
> >>> Then, nodes can connect to each other using whatever protocol of their
> >>> choosing.
> >>>
> >>> The pros are that this solution is simple to configure and maintain
> and that
> >>> the directory is not a performance bottleneck.  The cons are that it
> >>> requires a "central" directory service which is a potential security
> SPOF,
> >>> but that's perfectly acceptable to me for this problem.
> >>>
> >>> Maybe you have a better suggestion, but I don't see how I can do this
> with
> >>> the Harmony pattern.
> >>>
> >>> André
> >>>
> >>>> On Sun, Jan 18, 2015 at 1:17 PM, Pieter Hintjens <ph at imatix.com>
> wrote:
> >>>>
> >>>> I'd recommend reading about the Harmony pattern in the Guide.
> >>>> Router-to-router topologies tend to be nasty. I don't use them, and
> >>>> don't recommend them.
> >>>>
> >>>> On Sun, Jan 18, 2015 at 5:57 PM, André Caron <andre.l.caron at gmail.com
> >
> >>>> wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> I've been building an example of a router-router setup in which all
> >>>>> nodes
> >>>>> dynamically discover each other.  This currently works like a charm.
> >>>>> Now,
> >>>>> I'm trying to add curve support for this application, which is
> proving a
> >>>>> bit
> >>>>> confusing despite the API's apparent simplicity.
> >>>>>
> >>>>> Basically, all my nodes have a single router socket which is used
> both
> >>>>> to
> >>>>> connect to other peers and to receive connections.  However, I can't
> >>>>> seem to
> >>>>> do this when each peer has their own curve keypair.
> >>>>>
> >>>>> I have two problems:
> >>>>> - the same socket can not be a curve server and client at the same
> time
> >>>>> (so
> >>>>> I need at least both two sockets, one to connect and one to receive
> >>>>> connections); and
> >>>>> - a curve client can only set one server key so I cannot connect to
> >>>>> multiple
> >>>>> peers using a single router socket.
> >>>>>
> >>>>> The first problem I can live with -- have 2 sockets instead of 1 is
> not
> >>>>> a
> >>>>> major issue.  However, the 2nd problem is really annoying.  Creating
> a
> >>>>> new
> >>>>> socket for each logical outbound connection smes to me like an
> >>>>> anti-pattern
> >>>>> in ZeroMQ.
> >>>>>
> >>>>> So I'm wondering how I should handle this.
> >>>>>
> >>>>> I found this on the zmq_curve(7) man page:
> >>>>>
> >>>>>> A socket can change roles at any point by setting new options. The
> role
> >>>>>> affects all zmq_connect and zmq_bind calls that follow it.
> >>>>>
> >>>>> Is it safe to assume that I can simply set a new server key before
> each
> >>>>> zmq_connect()?
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> André
> >>>>>
> >>>>> _______________________________________________
> >>>>> zeromq-dev mailing list
> >>>>> zeromq-dev at lists.zeromq.org
> >>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>>>>
> >>>> _______________________________________________
> >>>> zeromq-dev mailing list
> >>>> zeromq-dev at lists.zeromq.org
> >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> zeromq-dev mailing list
> >>> zeromq-dev at lists.zeromq.org
> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150119/9c8834e7/attachment.htm>