> Wouldn't this issue also be mitigated by requiring the server to > re-authenticate during resumption with the certificate once in a while?
I think it's probably just easier to drop the resumption completely. > This two-lifetime thing is actually already what we implement in BoringSSL. 😊 Fantastic. Would it help to have an extension to set a lower bound on this value, or just make it more painful? Subodh ________________________________ From: David Benjamin <david...@chromium.org> Sent: Tuesday, January 29, 2019 1:02 PM To: Nick Sullivan Cc: Subodh Iyengar; tls@ietf.org Subject: Re: [TLS] ticket lifetimes This two-lifetime thing is actually already what we implement in BoringSSL. :-) We track both a lifetime for the ticket (one day) and also for the original authentication the ticket roots up to (one week). The lifetime of the ticket is bounded by both these values, and the latter is not extendable on renew. On Tue, Jan 29, 2019 at 2:18 PM Nick Sullivan <nick=40cloudflare....@dmarc.ietf.org<mailto:40cloudflare....@dmarc.ietf.org>> wrote: Wouldn't this issue also be mitigated by requiring the server to re-authenticate during resumption with the certificate once in a while? Existing servers won't do this, so I see this less as a mitigation and more as an optimization to plug the one-week-cliff that the fix produces. But, yeah, that would be handy. (Probably something like: "re"-auth'd identity apply to tickets, PSK applies to connection. Client sends an extension to advertise we're nearing the unrenewable bound.) David Nick On Tue, Jan 29, 2019 at 11:00 AM Subodh Iyengar <sub...@fb.com<mailto: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<mailto:christopherwoo...@gmail.com>> Sent: Monday, January 28, 2019 10:13:36 PM To: Subodh Iyengar Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] ticket lifetimes On Mon, Jan 28, 2019 at 10:04 PM Subodh Iyengar <sub...@fb.com<mailto: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<mailto:christopherwoo...@gmail.com>> > Sent: Monday, January 28, 2019 9:57 PM > To: Subodh Iyengar > Cc: tls@ietf.org<mailto:tls@ietf.org> > Subject: Re: [TLS] ticket lifetimes > > On Mon, Jan 28, 2019 at 9:43 PM Subodh Iyengar > <sub...@fb.com<mailto: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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=AeHpkYXwQtF4DjfqdHNluOLIcTHODTihn7i4WBzucjA&s=B4zL6Emv0jyhAsuJyBnxMzO8l1w7SDu5OpB4m8jarMk&e=> _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=AeHpkYXwQtF4DjfqdHNluOLIcTHODTihn7i4WBzucjA&s=B4zL6Emv0jyhAsuJyBnxMzO8l1w7SDu5OpB4m8jarMk&e=>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
