> On May 3, 2017, at 6:29 PM, Colm MacCárthaigh <c...@allcosts.net> wrote:
>
> Pervasive forward secrecy is one of the central security goals of modern
> cryptography,
Sure, given a sensible definition of forward-secrecy. And near instanenous
deletion of session keys is not part of such a definition.
> STEKs aren't compatible with this goal. They may be acceptable operationally
> today, but I think they must be borrowed time if the central goal is
> meaningful.
We need to recall what thread-model is behind the desire for forward-secrecy.
It is I think not controversial to say that forward is concerned with limiting
the damage from end-point (especially server end-point) compromise, in which
confidentiality of long-term keys (still held on the endpoint) is lost.
Consider the fact that such compromise is unlikely to be detected and remediated
instantaneously. Indeed not only will the adversary have access for some time
to sessions initiated post-compromise, he will also be able to impersonate the
real server after the server is "secured" because certificate revocation will
take days (or until the certificate expires) to take effect and more sessions
can be compromised via MiTM attacks after the keys stolen.
The incremental exposure of some fraction of a hour of sessions shortly before
compromise pales in comparison with the much longer post-compromise exposure
before the service is again secure.
STEKs are simpler to design and secure than a complex session cache. This
simplicity has security benefits. Properly implemented STEKS have a lifetime
that is much shorter than any plausible compromise exposure time window. Given
this, it makes sense to not consider potential STEK compromise as loss of
forward
secrecy.
Forward secrecy guards against disclosure of truly long-term key material, with
a lifetime of weeks to years. Once we get down to hours or minutes, it is quite
sensible to take a coarser view of time, with similar exposure for sessions
"just before" and "just after" compromise.
Maximally sensitive traffic can take the penalty of avoiding session caching
of any kind.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
