[Lurk] keeping private key private

[Daniel Migault <[e-mail]>]

Hi,



Following the discussions of the BoF in Berlin, I agree that the generic
principle for all TLS use cases mentioned in the BoF can be designated as
providing means to delegate TLS authentication.



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.



The short term certificate is for sure a useful mechanism, but the
mechanism does not prevent the leakage of the private key. Instead it
limits the use of a private key to a shorter period. This may be useful as
long as the time to retrieve the private key is longer than the life time
of the certificate which was not the case in the case of the Heartbleed
attack.



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.



BR,

Daniel