Wednesday, June 1, 2016< ^ >
Yoav Nir has set the subject to: IETF 95 - LURK BoF -
Room Configuration
Room Occupants

[12:42:21] sftcd joins the room
[12:43:02] sftcd has set the subject to: Virtual LURK BoF
[12:43:20] <eburger> I’m here
[12:43:20] <sftcd> hi eric, we using this jabber room today?
[12:43:28] <eburger> plan on it - I put it on the slides
[12:43:55] <sftcd> good stuff, I'll be a dial-in user so if you can get folks to say what slide they're on that'd be good, talk to ya in a few
[12:44:02] <eburger> will do.
[12:44:04] <eburger> see ya
[12:57:57] <sftcd> ouch
[13:01:54] Russ Housley joins the room
[13:02:09] <sftcd>
[13:02:25] <sftcd> rest of materials at
[13:02:50] yaron.sheffer joins the room
[13:04:18] <sftcd> sounds like loadsa new folks joining webex - maybe point 'em here again when that's settled down
[13:06:03] rsalz joins the room
[13:06:03] Martin Thomson joins the room
[13:06:08] <sftcd> please do record
[13:06:23] <sftcd> that sounded like Russ saying yes, wasn't me:-)
[13:07:11] kemaphant joins the room
[13:07:15] <sftcd> we're moving to I think
[13:09:38] hallam joins the room
[13:10:51] <eburger> Slide 3
[13:11:10] <sftcd> meaning slide labelled 3 and numbered 4 by pdf reader:-)
[13:11:24] <hallam> There seems to be an assumption here that 'the key' is one item in one place. I don't accept that assumption.
[13:11:29] <eburger> 😜
[13:11:37] <hallam> I want to be able to use split key
[13:12:01] <sftcd> I think it's true that daniel is assuming non-split keys yes
[13:13:52] <Martin Thomson> Oh, if R1 is a requirement, the BOF is over, we have to have a working group.
[13:14:04] <eburger> 🎉
[13:14:10] <sftcd> even if R1 is correct, the scope question remains
[13:14:22] <Martin Thomson> That was always the concern.
[13:14:23] sftcd not getting R3
[13:14:30] <Martin Thomson> Not getting R3 either.
[13:14:43] <Martin Thomson> Or R4
[13:15:05] <sftcd> R4 I get - says if you have a key server it needs to authenticate the LURK client
[13:15:29] <Martin Thomson> I understand that there is a slot that looks like that, but the text was weird.
[13:15:34] <sftcd> R5 seems tricky
[13:15:39] <sftcd> as in maybe-subtle
[13:16:51] <Martin Thomson> Are we talking signing oracle or decryption oracle.  That changes the dynamic.
[13:18:19] <sftcd> @phill: would it be true to say that split-key doesn't change the use-cases, but does change the language that ought be used to describe 'em?
[13:18:41] <Russ Housley> @Phill: Won't Boyd's RSA key split work for RSA in the way you suggest for two parties?
[13:20:32] <sftcd> to rich's point: I don't think even IEEE P1363 defined split keys did it?
[13:21:06] <Martin Thomson> Russ: I assume - for RSA signing
[13:21:49] <sftcd> right, for split keys, we'd be going back to the academic literature and working from there (not that that's bad but it is some work), could be a thing to ask CFRG about that
[13:24:22] sftcd thinks we could charter a WG before split-key support (or not) was decided but the WG would need to quickly decide to take that on or not I reckon as it'd change the protocol a lot, and one possible future would be to punt on that until CFRG had documented some good way(s) to do split-key
[13:26:48] <rsalz> ok
[13:28:15] <rsalz> Can we move on?
[13:29:17] <sftcd> +1 to we-dived-too-deep, but I think PHB's right that making the use-cases language independent of split-key would be a good thing, if it's doable easily
[13:29:35] <Martin Thomson> eburger: if I may, perhaps you could make this: should we consider mitigating compromise of the key server as a goal?
[13:29:39] <sftcd> I'm not sure requirements language can be made independent like that
[13:30:12] <Martin Thomson> the availability of split key systems does have some bearing on this
[13:30:37] <rsalz> fine.  tell us how to do it so that we know how to design the protocol so that it is not impossible to do it :)
[13:30:39] <sftcd> @martin: the containers/VMs use-case would naturally include key server compromise I reckon
[13:31:14] <hallam> [Of course patents on split key are one of the main reasons we have not done split key before. Fortunately patents do expire.]
[13:32:17] <hallam> ON R3, I think we need the device to be able to state what it can perform. Keep-alive and reachability seem out of scope.
[13:34:02] <sftcd> can someone speak to the container/VM use-case a bit more? are we talking vagrant or top-of-rack or both or what?
[13:34:21] <eburger> @Stephen - go ahead, you have a voice, too.
[13:34:37] <sftcd> yeah but I sound better typing:-)
[13:36:17] <eburger> (Ignorant chair question: is what PHB describing just PCKS?)
[13:37:31] <sftcd> yeah I have a question about the container/VM use-case, ping me when you want me to ask it
[13:39:42] <Martin Thomson> sftcd: can't we consider the authentication credentials to be at a lower privilege level than the primary key?
[13:40:05] <sftcd> I'm not saying it's a bad idea, just wanting to understand better
[13:41:14] <Martin Thomson> If the container is compromised, the keys can be used for the duration of the compromise; that includes authentication key leaks
[13:44:53] <sftcd>
[13:47:45] <sftcd> yeah the scaling of lurk would have to be less onerous than for all content, there still is something of a scale issue for the content owner though
[13:48:55] <Martin Thomson> I love the way that people say "a trivial REST API"
[13:49:05] <sftcd> aren't they all?
[13:49:20] <eburger> Only if you are not from the (RIP) Apps Area
[13:52:44] <sftcd> IOW basically all WebPKI certs are more or  less domain validated
[13:53:54] <hallam> +1 on out of band.
[13:54:24] <sftcd> well rogue-CDN or compelled-CDN
[13:54:25] <hallam> As I implemented, I found that 90% of my complexity went into the Admi->Keyservice link
[13:55:05] <Martin Thomson> EV is non-existence to a few orders of magnitude or so:
[13:55:10] <hallam> I am fine calling that 'out of band' and not doing that protocol at all.
[13:55:53] Yoav Nir joins the room
[13:57:04] <Russ Housley> I need to drop now to go to another call.  Bye.
[13:57:09] <Martin Thomson> It wasn't Julian Reschke
[13:57:39] <sftcd>
[13:58:15] <Martin Thomson> And this is an opportune time for IAB folks to leave for their call.
[13:58:25] <sftcd> happy IABing
[14:01:52] ekr joins the room
[14:02:53] sftcd thinks this is all a bit too much detail for today
[14:03:04] <ekr> sftcd: I agree
[14:03:45] <sftcd> @ekr: got any source for that thing you were saying about CDNs not wanting certs with their customer's name in?
[14:04:06] <sftcd> I'm wondering is it a cert thing or a private key thing? (likely the former given the current state of play I guess)
[14:04:27] <ekr> It doesn’t matter. They don’t want a credential that’s tied to the EE.
[14:04:36] <ekr> “Private communication” as they say
[14:05:05] <Martin Thomson> sftcd: it's also true that the opposite is very much true.  All connections have to show the customers name, so that the CDN has to have a cert with the customer's name.
[14:05:21] <sftcd> hmm;-)
[14:07:15] <eburger> I fixed my ding ;-)
[14:07:42] <rsalz> that sounds painful.
[14:09:07] Russ Housley leaves the room
[14:16:13] <sftcd> the specifics of the oracle aspects of a lurk server will have to be thrashed out in a putative WG, too early today I think
[14:17:29] <ekr> sftcd: thanks for pulling us back
[14:23:17] <sftcd> so this is the time to say which use-cases (if any) folks wanna address?
[14:24:20] <eburger> yup
[14:25:50] <sftcd> encoding is too detailed for today
[14:25:55] <ekr> Yes. Please say so.
[14:26:51] <hallam> +1 too detailed for today, too detailed for any day
[14:27:03] <hallam> Leave it open for future extension.
[14:27:49] <sftcd> how extensible to be is a fine question to ask just after we've decided there is something to do
[14:30:10] <sftcd> had 4 use-cases 1) container/VM 2) content provider 3) content-owner/content-provider and 4) CDNI - it'd help me if folks could say which of those they think ought be included if they support doing something
[14:35:56] <sftcd> #1 was VMs
[14:36:47] <Yoav Nir> Not the good kind of "randomness"
[14:39:00] <Yoav Nir> PHB's use case is different from the rest. IT takes place entirely within the code signer's supposedly-secure network.
[14:40:21] <sftcd> so if CDNI catch up to this and if a LURK WG exists, then the CDNI WG could ask "hey LURK dudes, give us a solution" I guess
[14:41:43] <sftcd> I'd guess trying to do the LURK trick between a dCDN and a uCDN might end up mega-hard
[14:43:52] <kemaphant> sftcd: yes.  I don't think CDNI is interested in solving this problem, but users of CDNI would probably be interested in a LURK-like solution.
[14:44:10] <Yoav Nir> As far as LURK is concerned, is there much difference between cloud, CDN, and hosting service?
[14:44:30] <sftcd> yeah, v. hard though e.g. if it needed a content owner to give the uCDN something it could give to any dCDN
[14:45:00] <sftcd> wrt AWS stuff, I think I heard Yaron say the business model is v. different and I suspect he's right. I've no clue if that'd affect protocol
[14:47:11] <Yoav Nir> +1 for BoF in Berlin
[14:48:44] <Yoav Nir> To clarify: +1 for WG-forming BoF in Berlin
[14:48:59] <Yoav Nir> Hopefully centered around #2 and #3
[14:50:16] <sftcd> right, there are more folks interested than on this call or even than on the list
[14:50:54] <sftcd> +1 to eric
[14:51:58] <Yoav Nir> I wouldn't read too much into attendance. There was a WG that had 250 people at the BoF, followed by WG meetings with 7 people, only three of whom had read the drafts
[14:53:07] <sftcd> that's fair, otoh, this is a thing that kinda changes the trust model of the web a bit (or recognises changes that have already happened in the wild;-)
[14:53:35] <sftcd> thanks to chairs to running this
[14:54:10] Yoav Nir leaves the room
[14:54:24] sftcd leaves the room
[14:55:30] yaron.sheffer leaves the room
[14:55:49] rsalz leaves the room
[14:56:00] ekr leaves the room
[14:56:03] ekr joins the room
[15:12:15] ekr leaves the room
[15:13:06] kemaphant leaves the room
[15:27:56] Martin Thomson leaves the room
[15:37:52] ekr joins the room
[15:39:52] ekr leaves the room
[16:34:11] hallam leaves the room
[17:51:58] eburger leaves the room
[17:52:50] eburger joins the room
[17:53:03] eburger leaves the room
[17:53:09] eburger joins the room
[19:58:30] eburger leaves the room
[20:08:14] eburger joins the room
[20:55:35] eburger leaves the room
[20:59:53] eburger joins the room
[21:28:08] eburger leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!