[zeromq-dev] zyre and curve key exchange

[Luca Boccassi]

On Fri, 2017-07-14 at 08:55 -0400, Wes Young wrote:
> > On Jul 13, 2017, at 1:54 PM, Luca Boccassi <luca.boccassi at gmail.com
> > > wrote:
> > 
> > As usual I would suggest to follow our process, and send a PR with
> > what
> > you have as DRAFT.
> 
> ack. did a first pass with #ifdef DRAFT, etc… now starting to clean
> up the gsl/xml bits and test to make sure the headers are correct..
> have a sep build process parallel to yours on opensuse to test this
> in our live env while we figure out the nuances [for those that want
> to play along].
> 
> https://github.com/zeromq/zyre/compare/master...wesyoung:feat/curve?e
> xpand=1
> https://github.com/zeromq/czmq/compare/master...wesyoung:feat/curve?e
> xpand=1
> 
> the thing i’m trying to work around is creating too many custom
> headers (which is easy todo, just looks awkward). so first attempt
> is/was to overload the SET/CONNECT variables and pick them apart
> before we connect/bind. which doesn’t break zmq_bind|zmq_connect but
> it does make the actors a little less … consistent.
> 
> i have a feeling, for the sake of consistency the better way is going
> to be setting each of the keys via the normal actor calls [which we
> started out doing, just more code vs overloading the endpoint SET]
> and passing the vars through the headers to the correct functions.
> 
> there are a few [simple] zcert functions that i think are no-brainers 
> to PR sooner than later, just cleaning up the obvious gsl/xml stuff
> there too.

Looks very interesting!

I would recommend using actor calls rather than overloading.

The endpoint format is already very overloaded and a bit confusing as
it is, having clear API calls is much cleaner and understandable for
users and developers IMHO.

> > I don't think the zbeacon protocol change can be made backward
> > compatible unfortunately, as the library checks for the exact size
> > of
> > the beacon, and discards if it doesn't match.
> > 
> > Also not sure it should in the first place - given it's a security
> > feature, it would open up to a downgrade attack. There were CVEs in
> > libzmq with the exact same problem when Curve was first introduced.
> 
> that makes sense. i kinda figured i was playing with fire on that
> one, but exploring the idea, getting it to work, etc. i hate having
> to do so much manual work (exchanging keys, etc) just to test stuff.
> it’s a pita (like having to remember wifi keys for basic tls
> functions). i get why, trying to think outside the box.
> 
> back to the drawing board.
> 
> > Perhaps add it as an option, but fail hard if it is enabled and the
> > peer does not support it. This way backward compatibility by
> > default
> > can be saved, but if enabled it's robust against downgrade.
> 
> i like this idea. may run with it a bit. it’s *probably* a new
> version of the RFC, just to be consistent, and then doing what you
> describe, make sure it’s not a default, but that you set it and it
> locks down. if only to see how it reacts in the wild.

It would be a new RFC yes, but it's fine, we can create version as
DRAFT and follow the usual process. Feel free to send a PR to create it
in zeromq/rfc, doesn't matter if it's rough on the edges, we can
iterate as needed.

> > Also note that it's not only on a local network anymore, zbeacon
> > supports IPv6 multicast and although rare and difficult, it is
> > possible
> > to use it beyond the LAN boundaries.
> 
> you should see the env we’re testing this in (*heavily* Internet2
> enabled ;), which is sorta why i’m asking some of these questions..).
> 
> thanks for this, very helpful :)
> --
> wes
> wesyoung.me
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170715/f28447b6/attachment.sig>