Wouldn't this issue also be mitigated by requiring the server to re-authenticate during resumption with the certificate once in a while?
Nick On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar <sub...@fb.com> wrote: > > If by "entire TLS session" you mean the resumed (and renewed) > sessions, then yep! > > Ya I think that'd need a new draft either way. Can definitely write that up > if people don't think it's the worst idea in the world. > > Subodh > ------------------------------ > *From:* Christopher Wood <christopherwoo...@gmail.com> > *Sent:* Monday, January 28, 2019 10:13:36 PM > *To:* Subodh Iyengar > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] ticket lifetimes > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
