Hi, The 3GPP requirement (as I understand them) would be to change certificates during a long-lived mutually authenticated “association”, where the association may or may not be a TLS connection. That requires sending the new certificates. With ever shrinking certificate lifetimes this becomes more important.
- Setting up a new TLS 1.3 connection is one good way to solve this, but might require changes to other layers in the protocol stack, which may or may not be problematic. - RFC 9261is application layer authentication and requires changes to the application layer. I don’t see this as a general solution. 3GPP wants authentication on the TLS layer without any changes to the application layer. - Post-Handshake Authentication seems to do the work, but cannot be used for the server and cannot be used in QUIC. I think I would like to see client and server Post-Handshake Authentication in both TLS 1.3, DTLS 1.3, and QUIC. Cheers, John From: Martin Thomson <m...@lowentropy.net> Date: Monday, 23 June 2025 at 03:37 To: Yaroslav Rosomakho <yrosomakho=40zscaler....@dmarc.ietf.org>, <tls@ietf.org> Subject: [TLS] Re: Certificate Update in TLS I've often thought that rechecking a certificate for a long-lived connection is a fine idea. That doesn't mean sending the certificate again; not always, anyway. Consider the baseline case: the authenticating peer wants to check that the certificate for the authenticated peer is still good. They could: 1. Just check that the timestamps are still good, considering the elapsed time. 2. Recheck revocation status: for very long-lived connections, this might mean getting a new OCSP response. Though OSCP seems like it is no longer in fashion, so maybe this instead involves checking against a fresh CRLite snapshot instead. 3. Get a certificate with a renewed signature from the CA, verifying that the public key is the same. None of these need fresh signatures on the connection. Only updated information from which to account for the passing of time and the potential for new revocations to become known. The first doesn't need any TLS changes. The second doesn't, unless you are using OCSP stapling. The third might, but I wonder if that isn't better addressed with an optional certificate extension (get updates to this certificate at this URL...) or something along those lines. On Sat, Jun 21, 2025, at 07:45, Yaroslav Rosomakho wrote: > Dear TLS Working Group, > > We would like to share a new individual draft, "Certificate Update in > TLS 1.3" (draft-rosomakho-tls-cert-update). This document specifies a > lightweight extension and two post-handshake messages that allow TLS > peers to provide renewed certificates on an active TLS 1.3, DTLS 1.3 or > QUIC connection without requiring session termination and > re-estabilshment. We see this proposal as highly complementary to the > Extended Key Update draft > > There is a growing set of use cases that rely on long-lived TLS or QUIC > sessions, including IoT communications, VPN tunnels such as MASQUE > CONNECT-IP, and carrier signaling. In these settings, tearing down a > connection to share an updated certificate can be costly and > disruptive. At the same time, there is a strong trend towards shorter > certificate lifetimes, which creates a tension between security and > operational continuity. > > This mechanism enables both peers to provide updated certificates > mid-session using Exported Authenticators. The specification defines > tight constraints on updated certificates to ensure that such updates > do not alter the logical identity of the peer or result in unintended > authentication or authorization changes at the application layer. > > We believe this solution addresses limitation of alternative approaches: > - Relying solely on initial authentication becomes increasingly > problematic as sessions grow longer. > - Using application logic to detect certificate expiration and > terminate sessions is fragile and cumbersome. > - Updating higher-layer protocols to handle signaling certificate > updates uniformly is infeasible and potentially disruptive. > > We do not expect this mechanism to be useful for short-lived session > such as typical web browsing when TLS sessions are significantly > shorter than typical certificate lifetime. > > It would be great to hear feedback on the proposal in general as well > as design specifics. > > Best Regards, > Yaroslav and Tiru > > > ---------- Forwarded message --------- > A new version of Internet-Draft draft-rosomakho-tls-cert-update-00.txt has > been successfully submitted by Yaroslav Rosomakho and posted to the > IETF repository. > > Name: draft-rosomakho-tls-cert-update > Revision: 00 > Title: Certificate Update in TLS 1.3 > Date: 2025-06-20 > Group: Individual Submission > Pages: 14 > URL: > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-rosomakho-tls-cert-update-00.txt&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C921b63f405344493054c08ddb1f6841f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638862394537538546%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ZfzznGgzdMxJDGr1lMcfTMTUSZG9aZm4isB41APL0AM%3D&reserved=0<https://www.ietf.org/archive/id/draft-rosomakho-tls-cert-update-00.txt> > Status: > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-rosomakho-tls-cert-update%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C921b63f405344493054c08ddb1f6841f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638862394537565126%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Vlyc%2B0CmO8tSJ2R6n%2FwYSZOFT1JgYdmqz9dn6osbwvE%3D&reserved=0<https://datatracker.ietf.org/doc/draft-rosomakho-tls-cert-update/> > HTML: > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-rosomakho-tls-cert-update-00.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C921b63f405344493054c08ddb1f6841f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638862394537579700%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7vsK5KEQ2%2F4JbwmsiFT8M15f5fEuaMpayb08K4hv3Bo%3D&reserved=0<https://www.ietf.org/archive/id/draft-rosomakho-tls-cert-update-00.html> > HTMLized: > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-rosomakho-tls-cert-update&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C921b63f405344493054c08ddb1f6841f%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638862394537593030%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WaIQZ%2BhhSDFFvEW4yIlk%2BTc8So7bBFf%2F7S5BUthwc9c%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-rosomakho-tls-cert-update> > > > Abstract: > > This document defines a mechanism that enables TLS 1.3 endpoints to > update their certificates during the lifetime of a connection using > Exported Authenticators. A new extension is introduced to negotiate > support for certificate update at handshake time. When negotiated, > either endpoint can provide a post-handshake authenticator containing > an updated certificate, delivered via a new handshake message. This > mechanism allows long-lived TLS connections to remain valid across > certificate rotations without requiring session termination. > > > > The IETF Secretariat > > > This communication (including any attachments) is intended for the sole > use of the intended recipient and may contain confidential, non-public, > and/or privileged material. Use, distribution, or reproduction of this > communication by unintended recipients is not authorized. If you > received this communication in error, please immediately notify the > sender and then delete all copies of this communication from your > system. > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
