AnsweredAssumed Answered

Session Tickets: Cap the Grade to B or C

Question asked by Matthias Wächter on Nov 30, 2015
Latest reply on Dec 7, 2015 by Matthias Wächter

After reading through How Session Tickets will compromise PFS, https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf, https://timtaubert.de/blog/2014/11/the-sad-state-of-server-side-tls-session-resumption-implementations/, https://www.imperialviolet.org/2013/06/27/botchingpfs.html [Edit: Links corrected] and alike, I come to the conclusion that once I activate (or don’t de-activate) Session Tickets, especially on a server that adheres to Section 4 of RFC 5077 - Transport Layer Security (TLS) Session Resumption without Server-Side State (Recommended Ticket Construction compliant servers), PFS is more or less dead, and to me it doesn’t look as if things would improve with TLS 1.3 at all (see Section 6.3.11 of the current draft spec The Transport Layer Security (TLS) Protocol Version 1.3).

 

While there is Section 3.4 of RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) which gives further recommendations regarding Session Tickets, the main topic nobody wants to express (except perhaps Slide 30 of Florent Daignière’s Blackhat presentation, »No point in using anything fancier than AES128-CBC!«) is that we see transmission of symmetrically encrypted session information (i.e., the session key) in any new client connection approach using a Session Ticket. This violates PFS.

 

And without PFS in effect we cannot grade a server setup as A, perhaps not even B.

 

Any thoughts?

Outcomes