Re: [Lurk] keeping private key private

[Daniel Kahn Gillmor <[e-mail]>]

Hi Daniel--

On Wed 2016-10-12 13:10:04 -0400, Daniel Migault wrote:

> Currently delegating a TLS service to a third party or multiple edge nodes
> is mostly based on distributing the full private key to multiple edge nodes
> that may even be in a different domain. Such a distribution prevents the
> key owner to keep the control of the private key as well as to prevent the
> key to leak. For example, with LURK, the Heartbleed attack would have had
> very limited impact as the private key would not have been hosted on the
> edge server. By design, LURK would have prevented the key to leak.

What's more important -- the secret key material, or the traffic and
information on your website that it protects?

When the certificate is long-lived, there are good arguments for the
secret key being more valuable, because it can be misused in the future
when we don't yet know what the value of of the traffic and information
will be.

It's also conceivable that a single cert (e.g. *.example.biz) could be
more valuable than any one site it applies to.

But when the certificate is short-lived and narrowly-scoped, the things
the cert is trying to protect are proportionally more valuable, though,
right?

secret keys are cheap!  certificates are (increasingly) cheap!  Making
cheap things less powerful and using them freely seems like a much
simpler approach than trying to invest certificates with lots of power
and then trying to find ways to avoid the misuse of that power.

> My understanding is that there are currently no mechanisms that prevent the
> keys to leak in the case of TLS. There is a huge demand from the industry
> to provide mechanisms that protects the private key from leakage. The
> reason we focused on TLS is that by limiting the use of a single protocol
> it provides more control on the usage of the key. However, the protection
> of the private key can also be handled in a more generic way outside the
> scope of TLS.  I would like to understand whether mechanisms to prevent
> leakage of the private key should not be handled in the context of TLS and
> instead being handled in a more generic way.

we have (a few) generic mechanisms already.  PKCS#11, as horrible as it
is, provides for secret key isolation.  "PKCS#11-RPC" was floated as one
idea in the LURK BoF, iirc, but i think it was (mostly) dismissed,
though i don't remember why.

But remote use of secret key material is also high-latency and prone to
bottlenecks -- are these engineering costs worth the benefits?

some people might amortize the costs of the high-latency handshake by
establishing and encouraging the use of TLS sessions; this is in effect
asking users to remember short-lived certs -- those sessions are going
to still be valid authenticators (to those end users) even after the
keyholder decides to rescind her grant of use of her secret key.

So there are a set of tradeoffs involved, and it's not clear to me that
the thing you're trying to protect is worth the energy and cost that
would be invested here.  can you explain how you see those tradeoffs?

All the best,

      --dkg