[zeromq-dev] zyre and curve key exchange

Wes Young wes at barely3am.com
Fri Jul 14 14:55:19 CEST 2017


> 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?expand=1
https://github.com/zeromq/czmq/compare/master...wesyoung:feat/curve?expand=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.

> 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.

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170714/ba4a67e2/attachment.sig>


More information about the zeromq-dev mailing list