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 inexp
