On Wed, May 3, 2017 at 5:51 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > 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. >
I want to re-run DH for every bit transferred! of course I'm kidding, and take your point. There's a balance to strike. > > 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. > In the case of STEKs, the key may also be compromised without compromising the endpoint. With multiple endpoints, there is usually some kind of central STEK distribution system to synchronize the keys. And they key may also be compromised due to weak crypto on the tickets themselves. So we have to add those too to the threat model. But caches have similar challenges, which might even be harder. > 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. > That does all makes sense, it just hasn't really been how TLS is deployed. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
