[zeromq-dev] zyre and curve key exchange

[Wes Young]

[thinking out-loud here, seeing if anyone is thinking about this]

tl;dr: has anyone messed with “overloading” beacon or gossip generally speaking? (curve or o/w).

i’m mapping curve down through zyre [and gossip] (using ZAP, etc), i’ve got a prototype working but thinking about trivial ways to enable basic public key exchange (forcing some of that up to ZAP where possible). starting with some trivial stuff, and working up towards the more complex issues (verification, key signing, etc).

i’m messing with the idea of modifying zbeacon packets to broadcast a peer’s public key along with their uuid, which seems to work OK, but prob requires a new ver of beacon RFC.

i rlz it may not make sense to enable crypto on a local lan where beacon works, but with the idea of zyre being “zeroconf” and helping people get their feet wet with zyre+curve, it presents an interesting use case for zyre+curve and getting folks to the next step w/o having to really get into the nitty details of authenticated keys first.

cheap, auto-negociated TLS at the expense of “breaking" current beacon RFC (although i can prob find a way around this since beacon is supposed to disregard ‘bad’ packets anyway?) also, spending some thought on how to map this to gossip (might need to overload endpoint PUBLISH or modify gossip_msg to signal keys where they exist).

judging by older threads, most people focused on the “central directory” model around making sure keys are “verified”, which is where i think you want to get. however i also think there’s something to be said for enabling semi-verified TLS where you can as you think through the problem (eg: using self-signed certs while you figure out how signed cert process fits into your app). curious if others are/have ventured down this path with zyre…

i think at the point in which i’m trying to break current RFC’s, it’s prob a good time to stake a step back and sanity check my view of the problem… i’d like a semi-in-band way of advertising public keys if it makes sense. i guess the work-around is a secondary oob service like others have done to “do essentially the same thing”.

i get that udp is ‘harder to trust’ than TCP (but we’re accepting that risk with the uuid already). similar for gossip, although we can build some verification into the gossip host too to aid with that instead of having to enable additional services (i think?)

feedback welcome.

--
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/20170712/ec6eb337/attachment.sig>