On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar <sub...@fb.com> wrote: > > In TLS 1.3 we added a maximum age to the ticket lifetime to be 7 days. This > had several original motivations including reducing the time that a ticket is > reused (for privacy or PFS). Another major motivation for this was to limit > the exposure of servers that use keyless ssl like mechanisms, i.e. if they > kept a STEK locally, but the keyless SSL server remotely, then the theft of a > STEK would presumably limit the MITM capabilities to the ticket lifetime. > > However thinking about it some more because of the renewal capability of > tickets in TLS 1.3, an entity owning the STEK could just re-issue new tickets > forever on a resumed connection. This would look to the client as a new > ticket and it would refresh its lifetime on the ticket. Thereby a MITM could > intercept connections to users that have been to the server with the STEK. > I'm wondering whether it might be useful to define a mechanism to limit the > lifetime of all ticket resumption across all resumptions from the original > connection instead of just the limited per ticket lifetime.
Since clients already store tickets, could they not also store the time of original ticket issuance and cap the resumption window to N (7) days from that point? That is, it seems clients could implement this behavior without any protocol support. Best, Chris _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
