On Wed, 2017-07-12 at 11:39 -0400, Wes Young wrote: > [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
Curve is the biggest missing feature from Zyre, so thanks for tackling it! As usual I would suggest to follow our process, and send a PR with what you have as DRAFT. 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. 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. 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. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
