Members present: jan____, ryan_ramage, Humbedooh, Wohali, benoitc, drsm79, wendall911, rnewson, TheJH
---------------- Meeting summary: ---------------- 1. Preface 2. TheJHâs Security Proposal 3. action items from last week IRC log follows: # 1. Preface # 19:10:37 [Humbedooh]: ACTION coughs at jan____ 19:11:48 [rnewson]: ah, I do recall the proposal. 19:12:00 [wendall911]: Having docs be encrypted would be crazy slow 19:12:07 [rnewson]: It seems to assume the replicator is specially privileged in some way. # 2. TheJHâs Security Proposal # 19:12:52 [rnewson]: I'm not sure what a secure solution looks like if you give couchdb the private or secret key. 19:13:01 [wendall911]: Not sure how it could be implemented in a way that wouldn't be so slow as to just not work at some point. This is why this type of thing is typically handled in the client 19:13:24 [rnewson]: wendall911 erlang can call native crypto libraries, I wouldn't assume it's too slow to be useful. 19:13:30 [jan____]: Humbedooh: oopsn, thx 19:13:30 [rnewson]: but that's not the hard part. 19:13:37 [rnewson]: as ever, it's key management. 19:14:17 [TheJH]: wendall911, well, that depends on how often documents are replicated, right? In my usecase, replication only happens when I get an email or set flags on it or so... so replication speed wouldn't be an issue for my usecase (but maybe that's too specific?) 19:15:01 [ryan_ramage]: I think that if/when the view server gets changed as discussed, it would be easier for people to build modules, one of which could be encryption 19:15:02 [Wohali]: ...That's a pretty narrow definition of when replication matters, and speed imo... 19:15:07 [rnewson]: let's ignore the speed issue please. 19:15:24 [rnewson]: and also remember that the replicator is just calling the http api available to everyone. 19:15:40 [TheJH]: rnewson, what specifically would be hard about key management? It's already possible to put passwords into the replicator DB without revealing them to other users, right? Why not keys, too? 19:15:52 [rnewson]: key management is de facto hard. 19:16:22 [rnewson]: how will keys be protected on disk? in memory? how can they be changed? revoked? 19:16:39 [wendall911]: Would it be better to handle encryped attachments? Wouldn't need to decrypt for replication then. Only would need to have keys on all masters, but wouldn't prevent getting a copy. 19:16:45 [rnewson]: do these sound like problems you'd expect a database to solve directly? 19:16:45 [Wohali]: If we do key management, people will start expecting things like PCI compliance, which is especially hard. 19:17:00 [benoitc]: Wohali: encryption should be a client thing 19:17:07 [Wohali]: yup 19:17:15 [wendall911]: benoitc: I agree 19:17:45 [TheJH]: hmm, so if I want fast access to the unencrypted data on my PC, I should just write a custom replicator? 19:17:45 [Wohali]: i could see key-based auth overall being beneficial, but not with the private keys in the db. 19:17:54 [rnewson]: attachment data can be completely opaque without breaking anything in couchdb, that's true. 19:18:30 [rnewson]: TheJH: decrypt it when you need to see it? 19:18:52 [rnewson]: rather than have the replicator acts a plaintext/ciphertext converter too. 19:19:00 [TheJH]: rnewson, that would make it impossible to make views on the documents 19:19:03 [rnewson]: yes. 19:20:10 [benoitc]: why do you need a pki btw ? It looks to me that a simple token is enough, token can be fetched during the authentication step 19:20:12 [benoitc]: in couch or anywhere 19:20:40 [benoitc]: couch only need an api to match keys to roles or access possibilities in that case 19:20:55 [benoitc]: that can be in couch or anywhere 19:21:10 [benoitc]: (coudl also work for ssl keys too) 19:23:02 [wendall911]: TheJH: so what is the goal of having encryption for your use-case? 19:23:40 [TheJH]: wendall911, if someone breaks into my server, he does not get access to all my past e-mail traffic (although he can intercept new mails in the future) 19:24:17 [jan____]: would an encrypted file system help? 19:24:17 [Wohali]: Have you considered using truecrypt for the volume that holds your CouchDB /var directory? 19:24:18 [Wohali]: :) 19:24:19 [wendall911]: because, in my mind if you're trying to protect the server, in a compromise, the keys would also be part of the server data, so data is compromised 19:24:25 [Wohali]: great minds 19:24:42 [wendall911]: however, if you store the data encrypted and support decryption in the client, you're protected 19:24:55 [wendall911]: couchdb is just a storage mechanism at that point 19:25:03 [wendall911]: imo, that's the only secure way to do it 19:25:11 [TheJH]: my goal is to protect data from people with root access to the vserver. my private key wouldn't be on that vserver, just in the couchdb I have at home 19:25:40 [TheJH]: there are two couchdb instances and I have different levels of trust in the systems they're running on 19:26:28 [TheJH]: truecrypt or encfs on the vserver's couchdb won't help because it would always be running 19:27:00 [TheJH]: however, if only the encryption key (not the decryption key) is on the server, the data is secure 19:27:46 [Wohali]: ( today's XKCD is appropriate. :) ) 19:28:35 [jan____]: :D 19:29:08 [TheJH]: yes, if someone owns my PC, it's over but if someone owns my vserver, it's not, and I'd like to further reduce the possible damage :P 19:30:00 [wendall911]: It's an excellent use-case. It might be a can of worms, but it's interesting to see if it could be supported in some way without pushing into PCI compliance territory 19:30:58 [jan____]: my gut says that this wants to be done outside of CouchDB 19:31:05 [Wohali]: I arrived late but the challenge of course is how secure the erlang VM is, too. Easy to get a remsh into that and then game over. And if Erlang doesn't know what the data means, it can't readily do anything useful with it. 19:31:42 [Wohali]: I think I came in just as the view server protocol was being discussed, so I'll skip that piece of the puzzle. 19:32:21 [rnewson]: Wohali: not that easy if it's not enabled.. 19:33:12 [Wohali]: I guess if you go down the SELinux route you could even block off access to /dev/mem. I'm just saying that it's a lot of things to worry about, and if we start down the road, we need to go all the way. Which means someone picking up this feature and shepherding it thru that process. 19:35:12 [wendall911]: Wohali: yes, and this could be a full-time job for someone for quite some time. I'm not sure it's a tenable situation at the moment without someone sponsored to do this work. 19:35:21 [TheJH]: Wohali, but that's not relevant to my proposal, right? You are talking about preventing exploitation of couchdb, I'm talking about reducing the impact of exploitation of the whole system 19:35:52 [Wohali]: Key word there is "reduce." Don't get me wrong, I love the idea, but I am immediately thinking of all the ways I could get around your proposed approach. 19:36:20 [wendall911]: TheJH: the point here is it's nearly impossible to secure an app in an insecure system. 19:36:50 [TheJH]: wendall911, but it's totally possible to secure its data. With GPG, your mail is secure even if someone breaks into your mail account. 19:36:59 [wendall911]: yep 19:37:15 [wendall911]: hence, attach it as data and couchdb works as-is 19:37:27 [wendall911]: attach it to a doc with some metadata for your views 19:37:35 [TheJH]: Wohali, if the private key isn't on the vserver and you only have access to the vserver, I think there can be no way to get around it 19:37:43 [wendall911]: the metadata can be stuff you're OK with anyone getting 19:38:05 [rnewson]: do we time-box topics in these meetings? 19:38:15 [TheJH]: wendall911, hmm... yes, that might work for me. 19:38:21 [wendall911]: I'm all done commenting, sorry :) 19:38:28 [TheJH]: rnewson, sounds like a good idea :D 19:38:36 [ryan_ramage]: I agree, in light of time, this discussion can move to the mailing list 19:38:58 [TheJH]: ok 19:39:00 [jan____]: Iâd +1 that 19:39:13 [wendall911]: TheJH: thank you for bringing this to our attention. Also appreciate the email to the list. Sorry there wasn't a better response there. 19:39:30 [jan____]: :) yeah 19:40:36 [TheJH]: well, thanks for the feedback so far :) 19:40:58 [jan____]: cool # 3. action items from last week # 19:41:13 [jan____]: ryan_ramage: all yours 19:41:29 [ryan_ramage]: ok, this is just time for reminders about action items 19:41:36 [ryan_ramage]: kind of a whip :) 19:41:58 [ryan_ramage]: if you want to get to the meat of these, most discussion is for the ML 19:42:13 [ryan_ramage]: just ack if you have done the action: 19:42:43 [ryan_ramage]: benoitc to send proposal to mailing list about the once a month meeting idea 19:43:38 [benoitc]: i didn't because was stopped by sonme comments I have to comments 19:43:43 [benoitc]: next 19:43:53 [ryan_ramage]: ok. wendall911 to start discussion on dev and add a page in the wiki to start gathering ideas for a formal proposal 19:44:21 [ryan_ramage]: ( javascript test update. View engine update/replacement. Removal of _restart) 19:45:06 [wendall911]: ok, I'm dragging my feet here, as I'm buried on a work project. I will have time in the next week to work on this. 19:45:28 [wendall911]: will discuss next week for certain 19:45:37 [ryan_ramage]: ok, this is just so everyone knows where its at. 19:45:43 [wendall911]: np 19:45:53 [ryan_ramage]: dch to update COUCHDB-1696 and prod the list on it 19:46:22 [jan____]: dch is out 19:46:36 [ryan_ramage]: have we felt prod'ed? 19:46:51 [ryan_ramage]: I think I saw some emails about this 19:47:28 [jan____]: ok 19:48:06 [ryan_ramage]: And I had an action to check on fauxton builds. and I now have to bug drsm79 for some code to check in to get it back working 19:48:28 [drsm79]: yes! I have the code 19:48:28 [drsm79]: need to commit it 19:48:36 [jan____]: cool 19:48:38 [ryan_ramage]: ok cool :) 19:48:43 [drsm79]: my bad - last weeks cloudant conf got in the way 19:48:51 [ryan_ramage]: ok, my section done 19:49:06 [ryan_ramage]: I can be a followup whip in the future, if this is useful 19:49:13 [jan____]: # Any other business 19:49:21 [jan____]: ryan_ramage: please :) 19:50:13 [Wohali]: 15:48 < drsm79> my bad - last weeks cloudant conf got in the way 19:50:21 [Wohali]: goes double for me 19:51:01 [jan____]: not to worry! 19:51:05 [ryan_ramage]: Wohali, drsm79 no doubt the conference will be beneficial to us all in the long run! :) 19:51:12 [jan____]: I was out most of the time as well 19:51:12 [Wohali]: indeedly doodly 19:51:20 [Wohali]: i guess i have something to insert here 19:51:50 [Wohali]: actually no, i'll hold it 19:51:57 [Wohali]: because i don't want to mention it until i really have time to focus on it 19:51:57 [jan____]: heh 19:51:59 [Wohali]: and i have a conference speech to give 19:52:06 [Wohali]: next week. 19:52:12 [jan____]: ok 19:52:21 [Wohali]: topic is automated hot upgrades compatible with package systems. watch this space. 19:52:50 [wendall911]: ACTION drools 19:52:57 [wendall911]: Wohali: awesome 19:52:59 [Wohali]: :) 19:58:50 [ryan_ramage]: ACTION prods jan____ to release our loose group of awesome back to our separate ways :) 19:59:20 [benoitc]: ACTION try to decrypt that sentence 19:59:35 [benoitc]: tries 19:59:44 [ryan_ramage]: benoitc: you need my keys, that couch can't store. sorry
