On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar <sub...@fb.com> wrote: > > > 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.
If by "entire TLS session" you mean the resumed (and renewed) sessions, then yep! Best, Chris > > 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
