> On May 3, 2017, at 8:45 AM, Colm MacCárthaigh <c...@allcosts.net> wrote:
>
> The fundamental problem with STEKs is that there is no forward secrecy
Sorry, STEKs are not long-term keys. So it makes little sense to claim
that use of STEKs breaks forward secrecy. Indeed STEKs may be more safe
than server-side storage of complete sessions, since the latter are much
more likely to end up on disk.
It is a shared meme that session tickets break forward secrecy, but it is
not correct. Poorly implemented session ticket keys can be a problem, but
so can poorly implemented session caches.
The distributed single-use caches you are imagining are very complex beasts,
and I am much less inclined to trust those than a comparatively simple key
rollover system (just three keys need to be known at any time, the past key
for as yet unexpired sessions, the current key used to mint and decrypt
new sessions and the future key created shortly before the current key becomes
the past key, giving enough time for all the cluster nodes to get a copy).
The time window for session compromise is never zero, after all, the keys
are in memory while the connection is active. It is unwise to insist that
forward-secrecy is broken if session keys are not destroyed instantaneously
at session closure. A reasonably short non-zero window of exposure may yield
greater security benefit than a design which appears to be more secure by
attempting synchronous destruction of keys at much greater overall design
complexity.
--
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
