> On May 2, 2017, at 10:44 AM, Colm MacCárthaigh <c...@allcosts.net> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
