20:00:26 <redrobot> #startmeeting barbican
20:00:27 <openstack> Meeting started Mon Oct 27 20:00:26 2014 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:32 <openstack> The meeting name has been set to 'barbican'
20:00:59 <redrobot> Hi everyone!  As usual, the Barbican Weekly Meeting Agenda can be found here:
20:01:03 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:01:11 <redrobot> #topic Roll Call
20:01:13 <hyakuhei> o/
20:01:19 <atiwari> o/
20:01:21 <alee> o/
20:01:26 <kaitlin-farr> o/
20:01:28 <woodster_> o/
20:01:32 <chellygel> \o\ /o/ |o|
20:02:21 <akoneru> o/
20:02:25 <hogepodge> \o
20:02:31 <redrobot> Woohoo!  Lots of barbicaneers here.  Good stuff.
20:02:38 <redrobot> #topic Kilo Design Sessions
20:02:56 <redrobot> I'm in the process of filling in the info for the Barbican Design Sessions
20:03:02 <redrobot> we have four slots, all on Tuesday.
20:03:10 <redrobot> should be a busy day
20:03:28 <redrobot> So far the topics are:
20:03:31 <redrobot> 1) Barbican Plugin (Driver) Lifetime management
20:03:39 <redrobot> 2) Common Certificate Issuance API
20:03:45 <redrobot> 3) Integrating Barbican with other OpenStack projects
20:04:36 <hyakuhei> 3 really has to move faster if you don't mind me saying
20:05:03 <hyakuhei> (I will be helping with that though, looking forward to discussing next week)
20:05:18 <redrobot> I'm tentatively holding the 4th slot for a Kite design session.  I've reached out to the Kite developers to see if they are interested in having a design session for Kite.  If not, we'll be using that slot for another Barbican discussion.
20:05:29 <redrobot> hyakuhei what do you mean move faster?
20:05:33 <hyakuhei> I know Tkelsey is very interested
20:05:49 <hyakuhei> So talking to a few Cinder devs about this the other day
20:06:05 <hyakuhei> Main objection seens to be a perception that Barbican API isn't stable
20:06:29 <rellerreller> We have bug with Barbican plugin in Cinder
20:06:56 <redrobot> hyakuhei I think there's some validity to that... we did change a lot of things in Juno.  I think we're committed to supporting the Juno API though, so hopefully this won't be an issue anymore.
20:07:12 <rellerreller> Sorry for being late. I only saw last three comments., but the latest python-barbicanclient has broken code for Barbican KeyManager
20:07:54 <rellerreller> I think this is second time now that this has been an issue for us
20:07:56 <redrobot> rellerreller yep, there's a lot of work that's going into python-barbicanclient that breaks things, which is why it's all targeted to a new major version release
20:07:58 <hyakuhei> redrobot: That sounds good, my main goal is to see decent encryption capabilities, using keymat from Barbican, integrated into OpenStack
20:08:29 <redrobot> #link https://launchpad.net/python-barbicanclient/+milestone/3.0.0
20:09:08 <hyakuhei> Useful link thanks
20:09:55 <alee> redrobot, if we have the fourth slot for Barbican, I'd like to vote for "User-level access to resources, such as secrets/containers / per-secret-policy" https://review.openstack.org/#/c/127353/
20:10:09 <atiwari> alee +1
20:10:20 <redrobot> rellerreller the only other pending change is to Orders.  Currently the client can't use the typed orders.  I should have a CR for that today or tomorrow.
20:10:23 <redrobot> alee noted.
20:10:46 <rellerreller> redrobot thanks
20:11:18 <redrobot> rellerreller once the Orders CR is merged, I'll release 3.0.0 to PyPI
20:11:28 <atiwari> redrobot, are removing the old style order from client
20:11:29 <atiwari> ?
20:11:43 <redrobot> atiwari yes.  No point in keeping it since the Server no longer supports it.
20:11:51 <atiwari> yes
20:12:21 <redrobot> Any more questions/comments regarding the Kilo Design Sessions?
20:12:31 <atiwari> yes
20:12:47 <atiwari> redrobot, can we organize our round table meetings too?
20:13:03 <redrobot> atiwari yes, we'll have a dedicated pod for Barbican, just like we did in Atlanta.
20:13:39 <atiwari> redrobot, ok
20:13:47 <redrobot> atiwari the goal will be to work through as much of the etherpad as possible
20:13:49 <redrobot> #link https://etherpad.openstack.org/p/barbican-kilo-design-sessions
20:13:58 <woodster_> general note: I've been adding additional items out there, along with a date stamp
20:15:30 <redrobot> atiwari anything else?
20:15:38 <atiwari> no
20:15:42 <redrobot> ok, moving on
20:15:49 <redrobot> #topic Atalla ESKM Plugin
20:16:03 <redrobot> I was hoping tkelsey would be around
20:16:17 <hyakuhei> I'll see if he's online
20:16:33 <hyakuhei> He isn't... This is an 8pm meeting in the uk.
20:17:01 <redrobot> hyakuhei no worries, I think we'll be talking about this in Paris either way.
20:17:28 <hyakuhei> Yeah I think so, it's a shame we can't move it along a little faster though
20:17:51 <hyakuhei> That goes for all/any HSM compatability
20:17:54 <redrobot> I added this to the agenda, since we were talking about it last week, and I've been thinking about whether it would be a good idea to add this plugin to Barbican when we know that it will be deprecated as soon as the KMIP plugin is up to speed.
20:18:07 <hyakuhei> Although having secure keymat with nothing to consume it is perhaps slightly redundant
20:18:42 <hyakuhei> We will be happy to support it in parallel with the replacement
20:19:40 <redrobot> I see.  The impression I had was that we would want to remove the current plugin as soon as the replacement was available
20:20:00 <hyakuhei> Sorry for giving that impression
20:20:16 <hyakuhei> From an accademic point of view KMIP is the better option
20:20:26 <woodster_> Why would we need both plugins active if KMIP is the better one?
20:20:37 <woodster_> active -> available?
20:20:54 <hyakuhei> So there are a few issues here
20:21:12 <hyakuhei> The first is that one is available now (almost) and KMIP will actually be a while
20:21:29 <hyakuhei> The KMIP secret store doesn't scale brilliantly as proposed today (stores everything in HSM)
20:22:42 <woodster_> By everything do you mean the keks themselves? If so, Paul (reaperhulk) moved to a MEK based approach with wrapped keks stored outside of the HSM, in Barbican
20:23:19 <woodster_> Is the timeframe for KMIP beyond Kilo do you think?
20:25:11 <hyakuhei> woodster_: for it to be stable, probably
20:25:17 <hyakuhei> Also, that's quite a long time
20:25:22 <atiwari> hyakuhei, as per this #link https://review.openstack.org/#/c/114580/4/specs/juno/hp-eskm-plugin.rst we storing everything in ESKM not just KEK.
20:25:27 <hyakuhei> Sorry I appeared afk for a second, network outage.
20:25:37 <atiwari> hyakuhei, is that correct?
20:27:08 <redrobot> hyakuhei no worries.  You missed a couple of Qs
20:27:17 <redrobot> <woodster_>	Is the timeframe for KMIP beyond Kilo do you think?
20:27:26 <redrobot> <atiwari>	hyakuhei, as per this #link https://review.openstack.org/#/c/114580/4/specs/juno/hp-eskm-plugin.rst we storing everything in ESKM not just KEK.
20:28:07 <hyakuhei> ok. so I'm not one of the primary contributors to the KMIP work. I'd like it to be ready before the end of the Kilo timeframe.
20:28:41 <woodster_> My only other comment was that if only project KEKs are stored in the HSM, reaperhulk address that via a MEK based approach that stores the MEK-wrapped project KEKs outside the HSM, in Barbican
20:28:46 <hyakuhei> woodster_: Where can I read more about Pauls approach to things?
20:29:28 <atiwari> hyakuhei, #link https://review.openstack.org/#/c/107775/4/specs/juno/restructure-pkcs11-plugin.rst
20:29:40 <hyakuhei> I think as of last week the basic model was CRUD for KEK all within HSM, DEKs stored by Barbican, wrapped by KEK as a HSM operation
20:29:48 <redrobot> hyakuhei http://specs.openstack.org/openstack/barbican-specs/specs/juno/restructure-pkcs11-plugin.html
20:29:49 <woodster_> well, we are working on a presentation for it in Paris :) But the basic doe is here: #link https://github.com/openstack/barbican/blob/master/barbican/plugin/crypto/p11_crypto.py
20:30:05 <atiwari> this is pkcs11 plugin in using MEK from HSM
20:30:36 <woodster_> yep, so the only thing stored in the HSM is a single MEK and a HMAK key
20:30:38 <hyakuhei> So my personal feeling is that you should have more scalable HSM resource, MKEK seems like a degredation
20:31:12 <hyakuhei> As in the event of a point-in-time compromise of Barbican you now have resident unwrapped KEK and DEK
20:31:16 <atiwari> hyakuhei, I think we need to clean #link https://review.openstack.org/#/c/114580/4/specs/juno/hp-eskm-plugin.rst
20:31:28 <woodster_> hyakuhei, perhaps, but if you wish to store 100k's of KEKs in the HSM, you run into issues with hardware availablity
20:31:45 <atiwari> as per this, it seems we are storing everything in ESKM .
20:31:47 <hyakuhei> Depends on your hardware
20:32:01 <hyakuhei> I mean, the HSM's we use store 2M keys
20:32:01 <atiwari> sorry If I am missing something
20:32:36 <hyakuhei> Maybe you should choose an appropriate HSM for load in the same way that you choose an appropriate chasis for compute
20:32:45 <woodster_> hyakuhei, my only point in bringing this up was if you KMIP issue was one of limited resources in the HSM.
20:32:48 <hyakuhei> At the very least both modes of operation should be supported
20:33:04 <hyakuhei> Sure I get that, I don't think that's the problem
20:33:32 <hyakuhei> In fact one thing I wanted to add to barbican at some point soon was the ability to indicate where a key was stored (ie which HSM) if that wasn't already there
20:33:39 <woodster_> hyakuhei, ok thanks for the clarification
20:34:06 <rellerreller> hyakuhei I like that idea
20:34:27 <atiwari> hyakuhei, woodster_, fyi I was proposing MEK approach with ESKM
20:34:31 <hyakuhei> To my mind that's how you scale without compromising key handling
20:34:50 <hyakuhei> I'm open to several approaches though, it's not a one size fits all kinda thing
20:34:51 <atiwari> something in same line as Paul's work
20:34:51 <redrobot> hyakuhei I'm still not sure what you mean by scaling
20:35:05 <alee> hyakuhei, rellerreller don't we already  have a mechanism to indicate which hsm stored a key by using the secret metadata?
20:35:09 <hyakuhei> where num KEK > HSM capacity
20:35:22 <hyakuhei> alee: I'm not sure, it's on my list of things to check
20:35:58 <rellerreller> alee I thought he was talking about exposing that to the external API, so you could call store key and store it using this particular secret store.
20:36:17 <redrobot> hyakuhei so, upon reaching capacity in one HSM you'd have to add another HSM to provide additional storage?
20:36:34 <rellerreller> alee The DB does store which secret store saved the key afaik
20:36:44 <hyakuhei> redrobot: That would be the same way that everything else works - everything has limited capacity.
20:37:09 <rellerreller> alee that is how we know which secret store to call to retrieve the key
20:37:19 <alee> rellerreller, right -- otherwise you would not know where to go to retrieve it
20:37:39 <hyakuhei> It's a risk managed decision if you want to offset the cost of adding more HSM against going down a MKEK route
20:37:53 <hyakuhei> However, I feel this is probably a discussion for next week
20:38:08 <alee> rellerreller, but if there is some kind of load/capacity decisions that need to be made, I'll not sure that should be exposed above the secret_store level ..
20:38:15 <hyakuhei> Fun as it is conversing at three sentences a minute it can be hard to keep track.
20:38:21 <redrobot> hyakuhei I see.  Not sure how much cost would factor into such a scenario.   We've found that the HSMs we're using have a very small capacity.  To add HSMs to add capacity would be prohibitively expensive.
20:38:47 <alee> rellerreller, how and why would the client have to know about which hsm to go to?
20:38:50 <redrobot> hyakuhei I agree :)
20:38:53 <hyakuhei> redrobot: Like I said, the ones we use today manage 2k keys
20:39:01 <hyakuhei> sorry, 2m keys :P
20:39:12 <hyakuhei> but they _are_ expensive.
20:39:48 <hyakuhei> real crypto security often is, I seem to remember us basically having the inverse argument lastweek
20:39:49 <rellerreller> alee It could be interesting for user to say store a key, and I want it to be stored using this provider. Perhaps I have a requirement to store things in KMIP and not other types of secret stores.
20:39:54 <atiwari> alee, I think if that are multiple HSM, you have to maintain the reference in secret .
20:40:21 <rellerreller> alee Perhaps not identify individaul secret store but secret store type
20:40:30 <hyakuhei> Yeah
20:41:07 <alee> hyakuhei, rellerreller ok - that makes sense -- I've proposed something similar for cert issuance.
20:41:25 <rellerreller> alee Yes, it is the same concept as that.
20:42:13 <alee> ok
20:42:15 <woodster_> hmmm....warning, API changes ahead :)  Well, additions anyway
20:42:29 <redrobot> yeah, will definitely be a fun week next week :)
20:42:40 <redrobot> so I guess we can table this until Paris.
20:42:48 <hyakuhei> I'm worried that we'll end up with a one size fits all here if we're not careful. If Paul's suggestion is the one I think it is, where secrets are stored in Barbican but most of the operations happen in the HSM then I think you'll still run into scale issues
20:42:56 <hyakuhei> Anyway, yes, table it
20:43:24 <redrobot> ok, moving on.
20:43:31 <redrobot> #topic Barbican T-Shirts
20:43:45 <hyakuhei> Finally something important ;)
20:43:56 <redrobot> so on a lighter topic, we _finally_ printed the shirts we promised during the mid-cycle
20:43:57 <atiwari> +1
20:43:59 <alee> hyakuhei, thats roughly how dogtag solves this problem -- and its scaled just fine for millions of secrets
20:44:44 <hyakuhei> alee my concern is that people buy the cheapest smallest HSM and watch it struggle with all the operations required. It's not the number of secrets its the number of crypto operations per second
20:44:54 <redrobot> so, if I promised you a T-Shirt at the mid-cycle, please let me know your size
20:44:57 <hyakuhei> anyway, t-shirts
20:45:08 <hyakuhei> redrobot: are they amazing?
20:45:18 <redrobot> hyakuhei yes, HSM throughput is definitely a concern for us
20:45:22 <alee> redrobot, do I get a t-shirt?  I was there remotely ..
20:45:24 <redrobot> hyakuhei and yes, they're amazing :)
20:45:34 <redrobot> alee indeed :)
20:45:45 <atiwari> redrobot, can I?
20:45:56 <hyakuhei> I wasn't around for the tshirt discussion - I think I'll make my own, the design is OpenSource I assume :P
20:46:00 <rellerreller> I don't remember anything about t-shirts. What a pleasant surprise.
20:46:01 <alee> redrobot, at least there was a massive projector sized image of me in the room.  larger than life in fact.
20:46:31 <redrobot> hyakuhei yep... hopefully vague enough to not get sued by the foundation.
20:46:48 <hyakuhei> redrobot: Man, I remember the hastle we had trying to get a logo for the OSSG.
20:47:09 <hyakuhei> Perhaps better to beg forgiveness than permission... someone might say.
20:47:45 <redrobot> atiwari yep, we should have a few extras... we'll be bringing them to Paris.
20:47:58 <atiwari> redrobot, thanks
20:48:15 <redrobot> Ok, that's all I have on the agenda for today.
20:48:21 <redrobot> Looking forward to seeing everyone in Paris.
20:48:38 <alee> redrobot, hey. do we have barbican stickers?
20:48:41 <hyakuhei> Me too!
20:49:12 <redrobot> alee no stickers yet.  maybe next time we get swag in the budget.
20:49:19 <woodster_> barbican HSM keychains for all!
20:49:37 <alee> ah well :)
20:49:54 <woodster_> we'll ask for a bigger budget next summit
20:50:15 <hyakuhei> woodster_: some of these? https://www.yubico.com/products/yubihsm/
20:50:45 <woodster_> yeah, those would be nice! We'll trade you t-shirts for those :)
20:50:50 <redrobot> hyakuhei yes!  With barbican logos.
20:51:09 <hyakuhei> That would be awesome
20:52:11 <redrobot> See y'all next week!
20:52:14 <redrobot> #endmeeting