LURK Interim BOF meeting Discussion notes ------------ Chair slides Eric Burger Goals for interim: Do we want another face-to-face BoF in Berlin? No dissent in posted agenda We have a jabber room lurk.jabber.ietf.org Session being recorded [BUT Eric screwed up and cannot find the recording] ----------------------- Lurk TLS/DTLS use cases Daniel Migault use cases - VM's, content provider, content owner/content provider, CDNI requirements - looking for feedback on R3 specifically PHB - split key may be necessary, hard to do in RSA, easy to do in EC/DH Yaron - why is this different than authenticating the key server? PHB - may not full trust box (Key Owner?) to have key Rich - do we have any split key documents or use anywhere? PHB - not sure, but is easy to do in EC/DH. Would just need new key formats ККККККdon't want to back us into a corner Rich - without the details, unclear how this can be a requirement Yaron - needs to be phrased in turns of threat modeling, etc. not in terms of algorithms PHB - need to insure that compromise of the system requires compromise of both devices (hard drives get sold later, etc.) [unknown] - we are expanding risk scope to include key server? PHB - yes Yaron - maybe diving too deep into this one? Eric B - will send to the list - do we want split keys added to the charter? questions in the jabber room on R3, R4 Martin - R3 does not make sense [audio cut out for ~30 seconds, missed discussion] ККККККККdoes not understand how we can implement a protocol that does not cover R3 PHB - did we mention generating keys in the first place? Daniel - only consider interactions between Server/Key Server, did not consider generation PHB - Кdo we need a configuration protocol? Yaron - we don't have protocols for configuring standard web servers PHB - most of the complexity implementing is configuration Stephen - container/VM use case, can the source of that use case please explain more? ККККККККККhow are we keeping secrets out of containers/VMs? Rich - if the TLS key gets out, any impersonation is possible, if Server->KeyOwner КККККККauth key gets out, not as bad - avoids hard revocation Stephen - needs more flushing out, a whole bunch of ways you can lose VM's Rich - less dangerous to lose Server->KeyOwner key Yaron - we need more precise definition of threat model ------------------------------------ delegating TLS certificates to a CDN Yaron Sheffer unhappy with every connection requiring a connection to another box - drive to use short term certificates Eric R - CDNs are for bandwidth reduction, also session resumption avoids LURK per-connection simple API w/ PKCS12 payload security considerations - - revoke in the event of compromise - needs protection from rouge CDN issuing certificate (this can be applied more generally) Rich - multiple certificate use case/splitting needs to be addressed here Eric R - CDN's do not want to have a certificate with an end-entity name in it Yaron - for certification/compliance reasons? Eric R - yes Eric - from the chat room - if you don't trust your CDN, you need LURK, if you do, you do not need LURK Yaron - the security considerations assume a rogue CDN (or a rogue CDN employee). You still trust the CDN with your content. PHB - gives more agility, but is more interested in the code signing use case, rather than CDN ------------------------------------------ LURK TLS/DTLS Content Provider Edge Server Daniel Migault [audio cut out for ~30 seconds, missed first 2 slides, audio problems fixed] skipping a few slides to avoid detailed protocol discussion ECDHE unpredictable signature - modified edge server random Eric R - the reason there is usually concern about this is cross-protocol attacks КККККККthis may still not be limited enough as you are only restricting 32 bytes in КККККККwhat gets signed Yaron - should we change the no generic signing oracle requirement? Eric R - Stephen in IM says that we should hold on to this for later ------------------------------------------------ PFS-preserving protocol for LURK Sam Erb - КККККККККAdd supported TLS versions? - КККККККККAdded Тsession ticketУ request - КККККККККAdded state field; so server can know when things like keys rotated - КККККККККOpen issues - КККККККККPHB Worried about ТclosedУ operations, for future TLS versions; e.g., not a number in an IANA registry - КККККККККPHB prefers another encoding ------------------- Use Cases - 4 cases 1) container/VM 2) content provider 3) content-owner/content-provider 4) CDNI Eric B - polling for interest < runs through room participants > PHB - interest in code signing (not including in list above) Eric B - there are 2 additional use cases [what was the second?] Eric B - do we want to write a charter & have a BoF in Berlin? < seems to be consensus to write a charter first > < consensus to meet in Berlin > Eric B and Yaron will take first pass at charter Eric B - wants to wait for Berlin to present charter to larger community