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

[Viktor Dukhovni <[e-mail]>]

> On May 2, 2017, at 10:44 AM, Colm MacCárthaigh <[e-mail]> wrote:
> 
> https://github.com/tlswg/tls13-spec/issues/1001
> 
> I'll summarize the summary: Naturally the focus was on forward secrecy and replay. On forward secrecy the main finding was that it's not necessary to trade off Forward Secrecy and 0-RTT. A single-use session cache can provide it, and with the modification that ekr has created in https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for both pre-auth and post-auth tickets, and it allows clients to build up pools of meaningfully distinct tickets.
> 
> There's also an observation there that it should really be that clients "MUST" use tickets only once. Any re-use likely discloses the obfuscated ticket age, which is intended to be secret. Right now it's a "SHOULD".

Well, just a few days ago there was a discussion of ticket re-use, and
I was re-assured that ticket re-use was likely to going to work just fine...

   https://www.ietf.org/mail-archive/web/tls/current/threads.html#23035

TLS is a general-purpose protocol, used broadly beyond just the browser space.
With TLS in SMTP there's no demand or need for 0-RTT and server resources are
often more constrained than you'd find on a CDN server farm.  Repeat connections
are spaced further apart, and session lifetimes are longer (Postfix defaults to
an hour).

For Postfix, going back to a server-side session *increases* risk of loss of
forward secrecy, because bulky server-side session objections are written out
an on disk database, and e.g. with LMDB (a COW database) may take a long time
to be deleted.  By contrast session ticket encryption keys (STEKs) are small,
kept in memory, and are overrwritten and freed after ~2 hours.

Going back to server-side sessions would reduce resumption security for Postfix,
and would make servers more susceptible to DoS through cache exhaustion.

On the client side, non-reusable tickets would require substantially more complex
cache designs, and probably significant changes in the session APIs and internals
of TLS toolkits rather late in the evolution of the TLS 1.3 support code.

I am far from convinced that the effort would not be better spent improving STEK
key management in TLS server farms, which will need to support TLS 1.2 in parallel
with TLS 1.3 for quite a long time (likely a decade or more).

I believe that the proposed change is well intentioned but counter-productive.

-- 
	Viktor.