Subject: [Lurk] LURK minutes - draft

From: Yaron Sheffer <[email-masked]>
Date: Sun, 10 Apr 2016 16:07:20 -0300

If you'd like to correct anything, please respond to Eric and
myself.

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.