- LURK - IETF-96 Berlin
- Monday 18:00-20:00, Potsdam III
- Chairs: Eric Burger (remote) and Yaron Sheffer
- > Chairs intro (Eric and Yaron, 10 min.)
- * Chair Slides <https://www.ietf.org/proceedings/96/slides/slides-96-lurk-0.pdf>
- Yaron Sheffer (ys) goes thru chair slides...
- ###
- > Use cases (Daniel Migault (dm), 20 min.)
- * LURK Use Cases <https://www.ietf.org/proceedings/96/slides/slides-96-lurk-1.pdf>
- [ daniel goes thru slides... skipped the LURK Requirements slides 6 & 7 ]
- dmitry belyavskiy: points at CDN Interconn use case -- CDN1 and CDN2 and content owner... need to have interactions between CDN2 and the key server
- dm: use cascading contractual arrangements
- ekr: question for chairs -- is there supposed consensus on these use cases?
- ys: we will discuss one specific use case in scope of the charter, use case 3 "content owner / content provider" use case -- this is the only one in scope for the proposed charter (it is the one agreed to on the mailing list)
- subodh: <missed it>
- martin thomson(mt): I am cdn provider, I have boxes in hostile environs, having them use lurk addresses this and, yeah, is same use case...
- MT: all these [use cases] boil down to same use cases..?
- ekr: says the 1st use case doesn't
- dkg: wrt content owner / content provider (CP) use case -- nothing prevents the CP serving the wrong data, right? ie we don't prevent them impersonating us, but if we wish them to stop, we have the ability to stop them, yes? this is what we're talking about?
- dm: correct.
- subodh: the charter is only for cert-based authentication? previously...only recently added lifetime restrictions for certs...are we doing only that? is the WG going to work on solutions for the things that aren't presently addressed?
- ys: we haven't discussed those from formal perspective, charter is about certs, <personal hat> if things can be added w/o client-side changes, then maybe -- client-side changes are out-of-scope (in proposed charter)
- alexander mayrhofer: did you consider the case for dnssec where you are signing a zone? have you discussed dns zone signing as use case?
- ys: we have discussed it a little bit, there was not enough intereset, out of scope for now
- subdoh: do you wish to take delegated certificate chains on too?
- ys: this is not wg yet.....the draft you refer to might mean client side changes and x.509 tweaks and it is out of scope per proposed charter...
- ###
- > Certificate delegation (Yaron, 10 min.)
- * Certificate Delegation <https://www.ietf.org/proceedings/96/slides/slides-96-lurk-2.pdf>
- [ yaron goes thru slides...]
- wrt: draft-sheffer-lurk-cert-delegation-00
- ys: on slide 3, notes that this is proposing sending the priv & pub keys to CDN, would be nicer to use a CSR...
- ekr: can send a CSR "template" without a pub key
- dkg: am not understanding this - what is the extra step of lurk when I already have ACME?
- ys: it is defining the URLs for the REST protocol, between CDN and content-owner (CO). That is, the CO gets certificate via ACME, then shares certificate w/ CDN using lurk restful protocol
- dkg: this is how you avoid changes to the client side ie CO doesn't become a CA?
- ys: yes
- slide 4: upon compromise (what to do)
- slide 5: security considerations
- ys: CDN could use acme to get itself cert(s) to long-term pose as the legit site
- ted hardie (th): there is work in acme that may address this, please write a draft if you feel it is new work for acme and we're rechartering and may include it
- ys: will wait for lurk (if created) to come up with a solution and then separate the acme-specific work off.
- th: please don't wait [...?], raising these points to the mailing list would be useful
- subdoh: somthing that would be useful is if you could request certs that are skewed towards past (?)
- phb: this is why most short-lived certs [have issues?] due to clock skew -- you're not able to use the web pki unless ur clock is sync'd to [ntp] within a day...
- ben schwartz: primary use for this is for users who are actually under attack, who use CDNs and are concerned that their keys at the CDN might be compromised. people in that position often use CDNs because they can't spin up enough infrastructure to fend off DDoS. maybe giving CDN restricted access to CA could be a better solution [...?]
- ys: yes, delegating the authority to issue limited-time certs is interesting but more complex than what this proposes, but yes that is an option
- dkg: wrt Cert Transparency -- CT logs get larger with # issued certs, and so this will cause a CT log expansion... just something to be aware of....
- ###
- > Protocol (Daniel, 10 min.)
- * LURK-TLS Protocol <https://www.ietf.org/proceedings/96/slides/slides-96-lurk-3.pdf>
- daniel(dm): this is a very early draft proposal
- slide 4: ECDHE Security - signing oracle
- ekr: ths is not correct -- the diff is the suffix is always under control of the edge server -- so, any tls 1.2 server exposes a signing oracle of first 32 bytes, plausible best case for lurk is the edge server has control of server random.
- dm: I'm coming to that in next slide...
- slide 5: ECDHE Sec: cross protocol attacks
- slide 6: ECDHE sec: cross prot attacks cont'd
- ekr: thinks misunderstanding the issue, the concern is that the (edge server) forges a non-tls message and signs it with the tls priv key -- it is not cross-prot between TLS versions, it is between TLS and other prots. [ see discussion on-list ]
- what we are trying to do is harden the system against abuse by edge svr -- thinks this is a tough problem and ought to just accept that and admit signing oracle prob can be mitigated but not solved...
- ys: charter is vague about this point because it looks like the signing oracle can be mitigated, but not be solved, so this room needs to decide whether partial oracle w/ caveats ... we are interested in such a solution [...?]
- phb: can't see why tls uses ? sig and key exchange -- need to reengineer tls - should not have signature in key agreeement...
- subodh: [can do whole svr key exchange on part of content owner ?]
- dm: well, what we are preventing is the 'leak' -- we need to make tradeoff between mitigation and centralization of control into the key server (KS) -- simply isolating the key is a significant problem
- ekr: this proposal handles only ephmeral cipher suites, so, opening bid for this bof is to not break tls clients -- so what about TLS RSA-static clients? you break them, yes?
- rsalz: breaks zero clients because they all support ephemeral (?) does it have to be a client written in this century?
- dkg: ...
- ys: goto charter discussion....
- ###
- > Proposed charter (Eric and Yaron, 10 min.)
- * Proposed Charter <https://www.ietf.org/proceedings/96/slides/slides-96-lurk-4.pdf>
- [ room reads proposed 2-page charter ]
- ys: notes that "widely deployed TLS cipher suites" includes static RSA due to wide deployemnt
- ###
- > Open discussion (30 min.)
- tero kivinen: wrt widely deployed ciphers if it is only 2..3% some cdns might say it is ok to not support them...
- eric nygren(en): might be ok to have specs talk about just two different servers playing roles rather than hard code the roles as CO and CDN...would be nice to keep out of scope tunneling thru the TLS connections...
- phb: not too keen on this, we need to first agree on approach, [...] and remote key use. if you look at short-lived certs, it'd be better to recharter ACME with short-lived certs. there's also use cases eg software signing...
- stephen farrel(sf): we had this discussion on the list and only use case folks have raised is the CDN one...
- phb: if tied to tls, you're tied to tls "now", and if you do tls-future you may want to do remote use differently
- dkg: am simpathetic with the goals, but not convinced that the gain and the engineering works will result in us ending up in a better position. no changes on the client side [...]
- is not convinced the secret keys are more valuable than the content they are protecting, eg this could be used for surveillance in a std'zd fashion
- ys: to DKG: there are two existing protocols out there today that do what you're proposing [edit: referred to PKCS#11 and KMIP]
- ekr: wrt not changing client -- we can deploy large % of TLS clients very quickly via browser update -- if the prot you design leaves a substantial % clients broken....need to figure out how big that % is (why?)
- ben schwartz: looked at ssllabs.com, no version of IE on WinXP supports forward secrecy, so all IE users on XP (a lot in some countries) are in your category. it seems like we could get what you want to do using a one-call REST API. post key-pair to a REST URL, set up a cronjob, I'm done. worried there is to much work here, overcomplicated solution
-
- rsalz: static RSA is important, need to address it. have servers in hostile lands (China, Russia, Virginia) and customers don't want to give those serers private keys...
- martin thompson: I wanna hear from people, apparently they have a solution currently, so if there is just one person in the room who has this, we're done. (asks people to stand up if they do, did someone come forward?)
- subodh: our use case is not the CDN use case, but the "we have server", technical aspects the same, but focusing on CDN use case may cause us ending up with a too specific solution. only thing that concerns me
- jhild: do care about the container use case
- andrei popov: we have use case where we have servers in untrusted locations, but don't thing lurk solves for that, rather short term certs better, RTT btween edge server & key server adds latency, and where edge server needs to authenicate to key svr, and key svr might be in untrusted location...
- ys: we will decide on those specifics if & when we have a working group...
- erik nygren: while I work for CDN, primary interest is actually interactioon between our servers. even if it ends up not being used widely between different parties, [...]. we should work through the different cases and [...], so that other people working on the same thing don't cut themselves on the sharp edges
- ys: if we stick to CDN use case, does that allow us to address tech issues well enough such that it covers other use cases you have in mind?
- erig nygren(en): ? contstrain to tls svrs in diff domains...?
- ?: from my point of view the restriction of (?)
- thomas fossati: as long is simple enough to implement is ok w/us
- diego lopez: apart from CDN which is interesting case [...]. addressing this in the scope of ? would make sense
- mt: andrei reminded me of key point not yet addressed: reason you put edge svr in untrusted locations is there's users there and want to lower latency -- is adding latency w/lurk reasonable then?
- phb: the lurk part is only a small portion of interactions so won't overwhelm latency
- sanja: even cdni ? but cdn deleg is useful
- sf: puzzled -- lots of folks said similar things last time but nothing occured on mailing list aftwards...
- phb: unless you design lurk so it is tls-only, "it works" but if you generalize it, will break...
- ys: ? [something about it iwll be same scope...]
- joe h: [agreed with a prior speaker]
- phb: if CT can't deal with 360 certs per endpoint per year. the idea of having a franken(?)-group, (?). reduction of cert life-cycle is going to happen anyway
- ys: mention cdn is because I think of short-term cert -- my focus is the CDN case -- almost everything discussed has been about CDN -- though it is somewhat different today....
- phb: you got to choose an approach before you charter, you can't charter and then decide between two completely different ways of doing it. if you're going to propose a way of short lived certs (?)
- sean leonard (jabber): with all of the private keys floating around on various services with the proposed LURK model, it would make sense to label or annotate private keys in a common way, to designate its intended use, or sensitivity. (These would be considered intrinsic properties of the private key, although they are not mathematical properties.) Perhaps common labels or attributes for private keys intended for remote-use (or for keys used for authenticating the untrusted entity to a LURK server) may make sense. Such common labeling might also help with identifying when to rotate keys out of service, for example.
- dm: we are interested in this solution and (will?) use it for our customers (?) -- prefer interaction with key server w/o short-term certs, do it every txn. not much discussion on mailing list, then if one usecase is addressed then others are also (in general)
- ys: but the cipher suite isseus are effected by the use cases, eg the static RSA issue
- dm: yeah, so we had the discussion on the ciphers, the one ppl thought were userful whatever the use case, so I think its a good question, but I think we adressed this question too. so the question might be, what cipher we want to support rather than what use case, because it depends on use case and deployment. so maybe the real question is which cipher
- stephan emile (se): have a question regarding use case: is the CDN interconnection covered by this use case here?
- ys: atm not
- se: ?
- ys: we saw very little traction, which is why there's only the basic CDN model on this slide (i.e. the charter)
- mike bishop: (1) have to agree w/phb that shortlived certs will occur anyway, so maybe we should just recommend this work to acme recharter (s) don't need to support widely deployed ciphersuites, have to support all widely deployed tls clients....
- ys: that was actually the way I understood [...]. the wording is not very good, it'd include some weird algos as well as PSK which is never used on the open internet, so the intention is to support nearly 100% of clients and not necessarily cipher suites.
- ben schwartz: I agree that short-lived certs are going to happen and are not a reasonalbe work item. use a cdn to get throughput advantage -- there handshake latency and long-term connection latency bennies
- running your own SSH (?) cerver, no availability advantage, if server goes down site goes down. in terms of security, (lurk?) compared to shortlived terms, revocation is shorter by a few days. window of benefit here is incredibly small
- ys: based on what we heared there, i'm kind of two minds if we need to talk about only the CDN use case or all four and will ask AD's advice
- sf: if the mailing list comes to life to discuss the other use cases maybe will change opinion, right now not hearing we're ready to go forward to a WG -- want to challenge that? am proposing to not take the ususal set of hums...
- ys: so....as one who added short term certs into the mix -- let's take 'em out and then ask the room if what we're doing is 'remote signing for tls' does that make things better?
- yoav nir: the working group shouldn't try to do that (what?, not sure if referring to w/ short-lived certs or w/o)
- joehildb: thinks there's some edges here that need to be addressed, but doesn't need a WG
- ekr: have a # props for having a key owner and a server and to arrange for the priv key to be on the edge svr -- sounds like it is a solvable prob [w/o a WG(?)]
- ?: yes
- dm: the product already exists, so the question is whether we want to have just one verison, i.e. one standard?
- rsalz: an alt proposal woon't meet akamai needs....we are most interested in the draft rsalz proposed....
- ys: I said remote signing for TLS, don't think that excludes your proposal and certainly does not specify one protocol or draft
- sf: is clear we are not forming WG today -- have further discussion on the mailing list -- need to see if appropriate for rechartered ACME...
- tedhard: rogue CDN server needs to be brought to ACME, during rechartering phase in september, need to have I-Ds available to discuss -- current focus is to complete ACME v1 -- if there's delay they are busy doing the latter...
- ###
- > Open discussion (30 min.)
- N/A
- ###
- > BoF questions and wrap up (Eric and Yaron, 30 min.)
- did not happen
- n/a
- end