NOTES - LURK BoF. Apr. 5, 2016
Yaron sets the table and encourages everyone to join the robust mailing list.
This is not a WG forming BoF. The goal is to explore the scope of the work and think of how it would be encoded into a charter. Also evaluate the technical solutions currently on the table. There has been good discussion in the mailing list, an appropriate number of drafts, and we expect more discussion to happen in this room.
Rich Salz presents “This is the problem” from the meeting materials deck. Focuses the discussion on CDN use case.
Rich Salz (RS): Problem Statement -- slides at: https://www.ietf.org/proceedings/95/slides/slides-95-lurk-1.pdf
One use case: blah.com wants to distribute its content via CDN and doesn't want to give away its private keys either because it doesn't trust the CDN or just because the CDN terminates the TLS connection in "hostile" areas. Two possible approaches: browser->CDN->key server; limit (e.g. to 1d) the certificate/key-pair lifetime. Another use case is code signing.
RS: draft-erb-lurk-rsalg -- slides at: https://www.ietf.org/proceedings/95/slides/slides-95-lurk-5.pdf
Re: terminology. Let's decide earlier and stick to that across all proposals.
Goals:
No decryption/signing oracle;
Stronger protection for session encryption keys (tickets);
PFS.
Protocol overview:
req/resp
transaction id (allow streaming / pipelining)
mutual-auth secure channel between Server and Key Server.
RS goes through the slides to illustrate the main RSALG features.
He notes that intent would be to make, if WG went in this direction, any related IP royalty free (cross licensed). There is one IPR declaration related to the draft presented.
Yaron confirms that as far as Rich knows there is no IP that applies to any of the other proposals we will see. Rich says no IP from Akamai as far as he knows related to other presentations; can’t speak for others.
Daniel Migault (DM): TLS auth with LURK -- slides at: https://www.ietf.org/proceedings/95/slides/slides-95-lurk-2.pdf
Auth methods that we should support:
RSA (for compatibility) - the recommendation is to not send the decrypted PMS back to avoid the decryption oracle syndrome -- rather the MS;
ECDHE_{RSA,ECDSA} - the recommendation is to provide the separate inputs to the server -- avoid building a signing oracle.
Clarifies that drafts support both TLS 1.3 and 1.2.
Eric Rescorla (EKR): re: ECDHE_ECDSA. Even if you split the parameters this provides an extremely powerful oracle. I don't know how to build it in a way that avoids the signing oracle. The feasibility of doing this in a secure way is critical for defining the work in this WG.
DM goes through protocol, crypto exchanges, transport options and the current draft list.
Oscar Gonzalez De Dios: We (Telefonica) made an open-source implementation of the key server based on draft-cairns-tls-session-key-interface. Please, take it (https://github.com/mami-project/KeyServer), make your own experiments, and provide feedback.
Phillip Hallam-Baker (PHB): A Remote Key Implementation -- slides at: https://www.ietf.org/proceedings/95/slides/slides-95-lurk-3.pdf
PHB goes through the slides.
Why? Losing control of the private keys -- e.g. on Linux / OS X, leaked through backup, lost device, etc. -- has catastrophic effects.
Use cases:
software signing
TLS server
HSM interface
Approach: natural complement to ACME (similar data format); e.g. fingerprints to identify public keys.
Usage: hello (opt), create (or import) a key pair, request key use (multiple times), dispose the key.
Stresses this is complementary to short lived certs and acme.
Frederic Fieau (FF): CDNi use cases -- slides at: https://www.ietf.org/proceedings/95/slides/slides-95-lurk-0.pdf
FF goes through slides describing the use case of delegation from upstream CDN (uCDN) to downstream CDN (dCDN) over HTTPS without handing over the private key. The LURK box is offered by uCDN to dCDN. We think this interfaces should be specified in the IETF.
Open Floor - Yaron asks speakers to focus on the problem statement before diving into solution details
PHB: sees a huge number of valid use cases. Is there a demand from remote key usage? Or with restrictions for specific applications? Doesn't see CDN case as primary use case
EKR: it would be nice to first be clear on what we are trying to do and what it should and should not do. Now is the time to ask “what would we ideally do and is it achievable”
RS: agree with EKR. On ML CDN was dominant use case - don’t see a need to bind what the key can be used for. Akamai uses this internally with own implementation.
Yoav Nir: To me content is more important than the key. How can I trust the CDN with the content but not the key. Is it OK to distribute bogus software updates signed with the key?
RS: customers ask for weird things as above. Hostile countries - key escrow layout is of interest of CDN in keeping keys at the customer
Daniel Kahn Gilmore (DKG): flip side is hostile country can say you MUST implement this to give them access remotely to the key. Code signing already works without LURK.
Erik Nygren: separation between mechanism of being able to produce content and handle key vs when is this a good thing to use.
Jana Iyengar: lots of interest in the space. Is this because it has been solved multiple times? Is there an argument for standardization?
PHB: to DKG: well-run software groups have solved the problem in a secure way. The average developer hasn't, which allows malware. On standardizing this: intranet sort of flavor.
RS: No it's an Internet thing: two different organizations talking to each other over the public Internet.
DM: we want standardization for interoperability. One content provider to many CDNs and don’t want many libraries.
Martin Thomson: Why does the CDN need my cert? Instead of serving off CDN’s origin name.
RS: clients want to serve from the top level name (e.g. financial, health-care institutions) want the original URL to show in the address bar. Customers want the EV green bar in top level URL. Some confusion over subresources - some want origin name to be consistent.
Kyle Rose: imagine cert pinning use cases in multi CDN use case.
Ian Swett: interesting work. Talking about standardization is wise because it's complicated and multiple implementations aren't a great thing for scalability and correctness
DKG: interested in PHB's comment on split key where neither party has whole key. Is any of this going to prevent a pinhead from being spearfished? No.
Mark Nottingham: it would be horrible to have to deploy a specific stack or library for each CDN - obvious standardization candidate. To MT’s comment: no longer state of the art to do subresources on CDN's origin. Don’t stop innovating on encryption in other forums too.
Jon Peterson: i agree there is a need for a standard. I hear 2 different problems - cdni is an open Internet problem. Which is more of a redirection problem and different than the CDN case.
Erik Nygren: echoing Ian Swett - there is enough different ways to get this wrong. Standardization is safer in long run
Martin Thomson: warns against ocean boiling. What are the merits of scoping this to pcks11 over RPC. Chair Eric shudders.
Yaron from floor: most of discussion so far has been about CDN - and we may be addressing the problem the wrong way. If I want to outsource my content to a CDN, that's because I don’t want to have scalable infrastructure for signing. As a result content owner will just give the private key to CDN(s) anyhow. OTOH short lived ACME certs can offer a scalable solution for this problem. Separate the CDN use case from signing boxes
PHB: The real question is: do you want to write the charter so that you do private key on a stick? Or a super limited scope like a remote box that does TLS only? Propose to charter as PKCS11 + restrictions on key usage with the only one restriction considered initially in the working group being TLS.
Richard Barnes: to address oracle issues we are going to have to be non generic - usecase based. There is however still a pluggable possibility that might leave door open to code signing in the future (TLS 1.2 and 1.3 are starters). Ossification is an issue here due to more moving pieces. LURK boxes will need to be upgraded to take new TLS features.
Jon Peterson: we can find a lot of things that have a superficial resemblance to this problem. But there are some hard differences like redirection. Focus on bounding and selected use cases rather than generic.
Martin Thomson: agrees Jon describes the right tack.
Jana Iyengar: +1 on narrow scoping. Make sure people are eager to deploy. Otherwise publish as BCP.
Jim Schaad (JS): problems with having to delegate EV certificates to CDNs. Is there some way we can make that more palatable? For example more granular certificates used by CDN, doing revocation work better, etc. In order to de-risk the problem that lead us here in the first place.
Eric Burger: can floor react to assertion that people won’t hand over EV cert?
RS: that's a commercial secret.
Martin Thomson: EV certs aren't special from my POV.
RS: they are special to the end users of customers. Like badging.
Martin: agreed but OV/DV/EV distinction isn't that important here.
RS: our experience says otherwise. But I agree with you :)
-------------------------
Eric Burger as chair: two questions: do you believe there is a problem to solve and the IETF is the right place to solve it.
Martin: are we considering competency and oracle questions first? (EKR has left room).
PHB: EKR was reacting to a presentation that asserted they had achieved restriction and he felt they hadn't. Restricting to TLS requires to do in IETF, because the TLS knowledge is here. PHB wants the ability to do unrestricted oracle with ability to add restrictions.
Ted Hardie: problem statement included restriction on creating a signing oracle. What edge does is sending some amount of bits to the key server which becomes a signing oracle. Clarity on that point would be valuable.
Eric Burger as chair - hum if you've read Daniel's draft: declared modest hum. Notes that Daniel’s draft does not ignore this aspect even if it might not be correct. That's an important distinction in a first draft.
Kyle Rose: EKR's issue was more about complexity than not achieving objective. Even after complexity it is still a signing oracle. Would like more info on PHB’s design - how is enforcement of restriction done.
PHB: IANA registry describes key protocol uses that constrains you. [kyle how do you distinguish any response from a different version?] at creation time uses are defined - incumbent on person designing the restriction (e.g. TLS)
Yaron as chair - TLS <= 1.2 is fixed. But we are still in position to influence TLS 1.3 if necessary.
DKG: i would be sad to block 1.3 on this. [cheers from crowd]. It's important WRT scope - are we OK with something that would require modification to existing clients. Can CDNs use something that require TLS 1.4?
Farrell: TLS changes would not be accepted for this until post 1.3.
Nygren: require backwards compatibility.. But we can learn from signature ordering etc. looking at HSM protocols etc. would be good
Thomson: any client changes would make this the worst solution ever.
Eric burger from floor: i keep wondering why are we talking about non PFS ciphersuites? Usually I hear because we can’t change the browser.
Thomson: I thought that was an operating assumption - can’t change enough deployed browsers to matter.
PHB: Why should we care about the signing oracle? The certificate has a specific purpose. If it's used for something else this is an error. I need to see a use case where the signing oracle makes a difference.
DKG: Its the extra things the attacker uses the cert for is the problem, not the content owner doing it. Existing mechanisms don't work for restricting usage of a given cert.
Kyle Rose: even if we do want an oracle we should take as a given that extra complexity without an effect is bad.
Nygren: not just a signing oracle, it's a signing and decryption oracle because you need to support static RSA for backwards compatibility - and then lose PFS.
Daniel M: what we did was presented different options without any changes to client or server.. We didn't solve the issue of the signing oracle - what can we change to do that?
Thomson: we don’t need to solve the problems here. We need to be sure we can solve them.
Eric Burger as chair: two questions: do you believe there is a problem to solve and the IETF is the right place to solve it. Includes IETF has the right competencies.
Chair: I hear not unanimous, but consensus on "there is a problem to solve and the IETF is the right place where to solve it".
Delegate to AD Farrell: Is there energy for CDN only? Or CDN and more? - declared that there is a significant amount for "CDN only", but slightly more for "CDN and more".
Eric as chair: who will write drafts? 7 .. review? 15-20 .. follow the work - strong hum.
Eric as chair: is the scope well defined and understood. Laughter ensues. No hum
Eric as chair: is a second BOF needed in Berlin?
MT: yes, do this again. The remaining confusion needs to be resolved and I can't see how that can be solved on list.
RB: We had no charter discussion, so yes, let's do that again.
RS: I agree, we need more time.
PHB: authors of current proposals should come together maybe this week to try and define a unified framework
Thank you Patrick McManus and Thomas Fossati for helping take notes. All remaining errors are the chairs' alone.