Re: [TLS] Security review of TLS1.3 0-RTT

[Colm MacCárthaigh <[e-mail]>]

On Wed, May 3, 2017 at 6:07 AM, Viktor Dukhovni <[e-mail]>
wrote:
>
> > On May 3, 2017, at 8:45 AM, Colm MacCárthaigh <[e-mail]> 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