> 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.
Correct, however the server currently provides a value for this, and clients do not enforce a lower bound on this. 7 days is an upper bound. Servers would provide a much lower value than 7 days practically. If I'm understanding your suggestion correctly, you're suggesting that clients change the meaning of ticket_lifetime_hint? That is not just limit it to the scope of the ticket but the entire TLS session? That would be fine to by me, however might break some folks. Subodh ________________________________ From: Christopher Wood <christopherwoo...@gmail.com> Sent: Monday, January 28, 2019 9:57 PM To: Subodh Iyengar Cc: tls@ietf.org Subject: Re: [TLS] ticket lifetimes 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
