Re: [TLS] ticket lifetimes

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 <subodh@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 <christopherwood07@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 <subodh@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 <christopherwood07@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 <subodh@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
>