On Wed, May 3, 2017 at 6:07 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > 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.
There's nothing enforcing that, and research has shown STEKs being used for long periods of time. I think if we ask the question "What is probably the weakest security point in all of TLS?" I would give STEKs a strong nomination. Some problems; * STEKs can be used for years at a time * STEKs can be used across many domains and certificates * STEKs are often stored unencrypted on disk, hardcoded in configs * No mechanism to enforce how tickets are encrypted. Could be RC4. Most likely is AES, which mode? * Tickets are replay-able, weakening the protections against side channels. Most common algorithm is not side-channel resistant. They just seem to undo a lot of the good work we do in moving TLS endpoints to better algorithms and security modes. > So it makes little sense to claim that use of STEKs breaks forward > secrecy. I don't think this is even a controversial claim; the draft itself describes it. STEKs do break 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. > STEKs often go in config .. which is usually on dist. Caches are most often in-memory only. > 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. > That's true about caches, but one of the points in the review is that the economics work a little different and may favor security. > > The distributed single-use caches you are imagining are very complex beasts > My bias here is that I work on distributed systems, but a single-key distributed hash table is one of the simplest things we build. Though I acknowledge that it takes good attention to detail to properly secure access, and the data. > 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). > You can take a hybrid approach where you use such keys to encrypt the data in the cache itself. I think that gives you the "good" combined security properties of both. 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. Others argue for something even stronger than this: that the keys should be ratcheted/rekeyed even while the session is still in use, to provide some forward secrecy for prior data on a connection that is still active. This is the general direction of best practice. > 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. > Yep, that is true. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
