Minutes for LURK at interim-2016-lurk-2
minutes-interim-2016-lurk-2-1

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