Hi Daniel – Good to see clarification below to at least some of the key
questions that had come up at the BoF re LURK protocol. And keeping with
clarifications, there was at least one more conversation that I recall where
question were raised around changes to cipher suites needed for clients to
support LURK. Has there been any progress in LURK as to whether those changes
can be quantified and scoped?
It would also be good to see if the discussions do not almost exclusively limit
itself on the certs, as it appears, there are choices, namely, the session key
interface; short term certificates; delegated credentials etc. So, importantly,
if there is consensus that discussion is merited on content and separation of
keys from the content, that would then help to focus discussion on above
choices. In terms of use case, there is/was consensus on at least the CDN use
case and would be good to discussion also moves towards other possible use
cases.
Best
Sanjay
[cid:image002.png@01D229FA.BD545870]
From: Lurk [mailto:lurk-boun...@ietf.org] On Behalf Of Daniel Migault
Sent: Friday, October 14, 2016 2:52 PM
To: Daniel Kahn Gillmor
Cc: lurk@ietf.org
Subject: [E] Re: [Lurk] keeping private key private
Hi Daniel,
Thank you very much for the feed backs. I will try to clarify the problem we
are solving, expose why LURK in my opinion address this problem in a "wise" way
and expose why short term certificate (STC) does not solve this problem.
Note that I am not opposed to STC, I think this is something good to be done,
however, it is complementary to LURK and not an alternative to.
The mail may be long, but feel free to split it into different threads. I will
be more than happy to clarify any aspects.
I agree with you that information delivered by a web site is what we must be
focused on and this is actually the goal of LURK* (in a TLS context). Although
the secret key material (SKM) and the information of a web site are two
different assets, they are not independent and protecting the information
requires the protection of the SKM. Information is characterized at least by a
content and an origin. An un-authenticated content such as a software for
example, does not have the same value if it is being downloaded from the
editing company or from public content sharing site. The motivation of LURK is
to provide the user the means to trust the origin and as such the information
delivered by the web site.
As a result, SKM must be protected as long as the information is delivered,
independently of the SKM characteristics which includes its life time.
I also clearly agree with you that protection of the SKM should be performed
with limited cost and as simple as possible.
It seems to me that LURK meet these criteria, which is the reason we would like
it to be standardized. As an observation, LURK like solution have been deployed
by CDN for example, and I believe their goals are not to consider the most
expensive and most complex solution. That said they might be other and better
solutions.
There has been some discussions on whether short term certificates (STC)
address the problem we want to solve that is either preventing the leak of the
SKM or in a TLS context providing means to trust the origin of the information.
In addition, there were also discussions on whether STC are also less expensive
and more salable than LURK. I disagree that STC is an alternative to LURK.
a) First STC does not address problem we are trying to solve, i.e "ensuring
the origin of the information". In that context, STC limits the use of a SKM
that leaks to a short period of time. The improvement over long term
certificate is only valid if leakage of the SKM only happen accidentally - that
is one time or when retrieving the SKM takes significantly longer than the life
time of the SKM. Such limitation to the protections of the SKM are ways too
narrow. SKM does not address for example any attacks that can provide access to
the SKM in an timely manner. Such attacks simply needs to be re-done after any
SKM renewal. Such attacks includes for example privilege escalation
vulnerabilities which there is little ways to insure they will not happen.
Heartbleed is typically an existing attacks that only took an RTT to retrieve
the SKM. STC does not either address this attack - which we know exists - and
may take years to be disclosed. I see LURK ways more powerful as it address the
root cause of the problem instead of limiting the consequences of a leak. .
b) Second, STC are really not inexpensive at all.
b. 1) I might agree that generating a key is inexpensive. However we
should also consider that generating keys with a high randomness frequently
might not be as inexpensive as expected.
b .2) That said certificates are not limited to key generation and
includes signing by the CA as well as revocation when needed. Even though the
cost of signing by the CA decreases, if the number of signing operations
increases in several order of magnitude, the overall cost may not decrease.
Especially the cost may remain significantly high for EV certificates and for
these certificates STC may happen to be very expensive.
b. 3) STC as any certificate based solution does not provide
appropriated delegation mechanisms. As result, in a context of CDN, any time
the content owner changes the CDN a complex revocation procedure might be
required. Complexity may be due to the use of EV certificates as well as the
interrelations between the CDN and the content owner.
c) Third, STC as certificate based solution considerably weaken the
security.
c. 1) As certificates does not provide delegation mechanisms, the
delegation to a CDN often result in providing the SKM to a thrid party. This
goes against the principles of public cryptography, resulting in a
authentication that provides little benefit over self signed certificates.
c. 2) EV may present delays that are non compatible with STC, as a
result, the use of STC in our context may be limited to DV certificates which
is the weakest certification level.
LURK instead
a) solves the problem we are trying to solve as it prevents the leakage of
the key.
b) is inexpensive as it does not affect the operations performed by the CA.
At least the cost remains the same as it is today. I think one reason people
see this solution as expensive is that most people think of the key server as
an HSM. HSM is probably an expensive alternative, but there also less expensive
alternatives that includes the use of open hardware security modules [1],
software implementation of the key server in which case the cost is really the
instantiation of the VM. This is typically less expensive than the resulting
operations, traffic from STC.
c) is secure and with multiple level of security. The key server may be
only hosted by the content owner, provided to CDNs in different ways. Note that
providing an obfuscated key server (like an HSM) to the CDN still provide more
security than providing the key and limit the risk of leakage. In addition by
clearly splitting the SKM and session termination functions, LURK is likely to
ease the deployment of TLS over CDNs and as result the deployment of TLS.
I agree with you that having a key server adds an exchange between the server
terminating the TLS session and the key server which may result in higher
latency. The latency clearly depends on where the key server is located. In
case a high latency matters, the key server may be deployed close to the
terminating nodes. Of course there is a trade off between high security
requirements and low latency requirements. LURK makes this trade off possible
whereas certificates clearly prioritize the latency over security. That said,
the acceptable latency also depends on the information delivered by the web
site. Suppose the information is an update, latency does not really matter,
similarly if the content is a movie a additional .5 second might be acceptable
too.
I do not really agree that LURK presents a scalability issue. I agree that the
model of LURK is more centralized that the model proposed by SFT, similarly to
what DNS is versus hostnames files. Of course the key server needs to be
deployed so that it serves the expected traffic, and a single instance of key
server may not be appropriated. On the other hand, by centralizing the private
key operations, it makes the deployment of a new private key way easier. Only
the key servers have to be provisioned with the private key. Maybe we could
also associate the key server with a distribution of certificates which STC may
designed. Again I do not see STF are competing LURK but more complementing it.
BR,
Daniel
* For clarification let's call LURK the solution that consists in remotely
perform secret key operations.
[1] https://www.crowdsupply.com/cryptech/open-hardware-security-module
On Wed, Oct 12, 2016 at 5:45 PM, Daniel Kahn Gillmor
<d...@fifthhorseman.net<mailto:d...@fifthhorseman.net>> wrote:
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<http://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
_______________________________________________
Lurk mailing list
Lurk@ietf.org<mailto:Lurk@ietf.org>
https://www.ietf.org/mailman/listinfo/lurk
_______________________________________________
Lurk mailing list
Lurk@ietf.org
https://www.ietf.org/mailman/listinfo/lurk
