Subject: [Lurk] LURK Draft Interim meeting notes

From: Eric Burger <[email-masked]>
Date: Fri, 3 Jun 2016 19:53:27 -0400

Thanks to Sam for the notes!
LURK Datatracker Info Page: https://datatracker.ietf.org/wg/lurk/meetings/
PLEASE RSVP +1 / corrections by June 10.
Thanks.

LURK Interim BOF meeting

discussion notes

------------
chair slides
 Eric Burger

declared quorum

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 neccessary, 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
 [unknown] - 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 percise definition of threat model

------------------------------------
delegating TLS certificates to a CDN
 Yaron Sheffer

unhappy with every connection requring 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 - mupltiple 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 ceritifcation/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
 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 conensus to write a charter first >
Eric B and Yaron will take first pass at charter

Eric B - wants to wait for Berlin to present charter to larger community