(Did you mean upper bound?) > Na I meant lower bound. That is such an extension would be useless if the > time the server mentioned > time the client decided to cache it. However the > server might advertise a time < time the client decided to cache it, in which > it would be useful.
> I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound on > the renewability, but apparently that's not how others read it! > Though, I guess, having not specified it this way from the start, the server can't be sure the client honors the extension. I don't know what consequences that has for server-preference scenario. Yup I think there is a disconnect between the intention of the server operator and the protocol. That is the server operator would like to have only 7 day uses of the PSK, however unbeknownst to then, their library is renewing the ticket and extending the lifetime of the PSK. This disconnect exists in both TLS 1.2 and 1.3, however for TLS 1.2 the renewal of tickets is less widely deployed than it should be because of some historic client intolerance of it. I think the interpretation that the lifetime applies to the current ticket only is the more common interpretation. I did a short study of several TLS 1.3 implementation shandling of ticket lifetimes by staring at some code really intensely: OpenSSL: Leaves ticket management on the client to the caller via callbacks and doesn't enforce anything by itself. NSS: Looks like it treats the lifetime of each ticket independently and enforces the ticket lifetime. https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/tls13con.c#459 <https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslnonce.c#726>https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslnonce.c#1202 https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/tls13con.c#4661 OpenJDK: Ignores lifetime hint after checking that it is < 7 days and then uses a jdk specified timeout which is a default of 1 day http://hg.openjdk.java.net/jdk/jdk11/file/68fa3d4026ea/src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java#l336 http://hg.openjdk.java.net/jdk/jdk11/file/68fa3d4026ea/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java#l65 boringssl: Has the ability to use an internal session cache. Before it uses a ticket it checks the session timeout against current time. Everytime it receives a new session ticket it clamps the SSL_SESSION's timeout using ssl_session_rebase_time and then clears any timed out tickets with SSL_CTX_flush_sessions. Fizz: Treats each ticket lifetime independently. mbed tls: Leaves it to caller with mbedtls_ssl_conf_session_cache. However the API doesn't allow mbedtls to verify whether or not the ticket_lifetime has exceeded and its up to the caller to verify this. Seems like there is room for clarification on the ticket lifetime. Subodh ________________________________ From: David Benjamin <david...@chromium.org> Sent: Tuesday, January 29, 2019 2:52 PM To: Subodh Iyengar Cc: Nick Sullivan; tls@ietf.org Subject: Re: [TLS] ticket lifetimes On Tue, Jan 29, 2019 at 4:14 PM Subodh Iyengar <sub...@fb.com<mailto:sub...@fb.com>> wrote: > 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? (Did you mean upper bound?) I'd actually interpreted the RFC 8446 text to imply a 7 day upper bound on the renewability, but apparently that's not how others read it! I don't care strongly either way about an extension to set a renewal bound, I think. A client is always free to tighten ticket lifetime policies unilaterally. We don't need an extension to advertise its policies unless we want to allow server to change their behavior in response. In the other direction, if we think the server may also have an opinion on renewability (you mention keyless things), a NewSessionTicket extension would be easy to support. The client would then use the more restrictive of the server's preferences and its local policy. Though, I guess, having not specified it this way from the start, the server can't be sure the client honors the extension. I don't know what consequences that has for server-preference scenario. (For completeness, BoringSSL doesn't allow TLS 1.2 ticket renewals to extend lifetime at all, only TLS 1.3, and TLS 1.2 lifetimes are capped much more tightly. Since TLS 1.2 resumption doesn't involve an ECDH operation, any concerns about a stale online signature are overshadowed by how much data the client is willing to make vulnerable to a single session secret. We'd probably do something similar if we implemented TLS 1.3's plain psk_ke, but we only do psk_dhe_ke.) David Subodh ________________________________ From: David Benjamin <david...@chromium.org<mailto:david...@chromium.org>> Sent: Tuesday, January 29, 2019 1:02 PM To: Nick Sullivan Cc: Subodh Iyengar; tls@ietf.org<mailto: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
