Thanks for the feedback Jay and Casey, > We trust the network on which we run and we aren't getting and setting any sensitive data. > I value speed. I would continue to use a previous version of the charm.
Perfectly reasonable response, but be aware that the older charm implementations aren't receiving updates going forward. But that does make an interesting point, I encountered the same prickly situation when we were pioneering with the folks over at Expeto using layer-docker right after we enabled TLS terminated endpoints for swarm and Docker Engine. I feel we're headed to the same boat of secure by default, fine: but make it configurable. Which gets tricky once workloads are humming away. Stripping away TLS certificates before the consumers (related applications) are updated can cause dropped connections. (bad certificate errors, service unavailable, etc.) >Etcd really doesn't handle a high volume of writes anyway though. The overhead of a TLS handshake can be minimal, it just depends on the algorithm & key lengths used. This > should be configurable in the layer, I think. EC and 2048-bit RSA have reasonable handshake times. Yep, we're currently on the 2048 bit RSA key generation bandwagon with layer-tls. I think we're right in the grey zone of still reasonably secure, but it could go either way in the couple months/years, requiring the 2048-bit to be bumped up. Jay would really hate that overhead and I would be right along with him to be honest. #noloveforprimes But good feedback for making it configurable. I took the liberty of filing a bug about this: https://github.com/juju-solutions/layer-tls/issues/38 Great feedback! Thanks for taking the time :) All the best, Charles On Wed, Jun 15, 2016 at 5:08 AM Casey Marshall <casey.marsh...@canonical.com> wrote: > On Wed, Jun 15, 2016 at 11:52 AM, Jay Wren <jay.w...@canonical.com> wrote: > >> On Tue, Jun 14, 2016 at 5:50 PM, Charles Butler < >> charles.but...@canonical.com> wrote: >> >>> - There is currently no way to disable TLS wrapped endpoints on Etcd (we >>> want to keep our coordination data secure don't we?) >>> >>> >> For our use case, we consider the overhead of establishing a new TLS >> connection for every read or write to be heavier weight than we wish for >> our etcd clients. We trust the network on which we run and we aren't >> getting and setting any sensitive data. >> >> I value speed. I would continue to use a previous version of the charm. >> > > Etcd really doesn't handle a high volume of writes anyway though. The > overhead of a TLS handshake can be minimal, it just depends on the > algorithm & key lengths used. This should be configurable in the layer, I > think. EC and 2048-bit RSA have reasonable handshake times. > > 4096-bit RSA for TLS server keys is really slow though, I've seen > handshakes on the order of seconds when benchmarking. > > >> -- >> Jay >> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> -- Juju Charmer Canonical Group Ltd. Ubuntu - Linux for human beings | www.ubuntu.com Juju - The fastest way to model your service | www.jujucharms.com
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
