Hi Eric, There are two groups of cases with long-lived sessions that I regularly have to work with:
1. VPNs and VPN-like encapsulations using UDP/DTLS, TCP/TLS or QUIC. The underlying transport for site-to-site tunnels can be very stable - particularly with QUIC transport. On well connected sites these tunnels can easily stay up for months. TLS reconnection can be very disruptive as encapsulated transport flows would be typically terminated - especially in the case of tunneling technologies that directly encapsulate TCP segment data or UDP datagrams without inner IP layer such as HTTP CONNECT/CONNECT-TCP/CONNECT-UDP. On top of that, load balancing in distributed environments does not help as the new connection is likely to land on a different node, so graceful recovery is not always possible. 2. IoT control and metric streaming. Some applications of IoT are very sensitive and loss of connectivity can carry significant risks. Transport reconnection can lead to a brief loss of control or missing metric information, hence a full blown reconnection and a new handshake to revalidate peer certificate is not acceptable. Ability to signal certificate update in TLS session would help mitigate identity and certificate private key compromise risks as explained previously without disrupting connectivity. While recovery can be graceful, reconnection does take a bit of time - particularly if the IoT compute power is very limited. Best Regards, Yaroslav On Sun, Jun 22, 2025 at 4:37 AM Eric Rescorla <e...@rtfm.com> wrote: > > > On Sat, Jun 21, 2025 at 4:05 AM tirumal reddy <kond...@gmail.com> wrote: > >> 3GPP also has a requirement to secure SCTP-based communications using >> DTLS, which involves long-lived sessions. One of the key security >> requirements is that mutual authentication must be used, with periodic >> re-authentication to allow certificate updates (see Section 4 >> <https://www.ietf.org/archive/id/draft-tuexen-tsvwg-sctp-dtls-req-00.html#section-4> >> for >> more details).These connections are expected to remain stable for long >> periods of time. >> > > What I'm trying to push on here is whether it's in fact a good pattern to > have > long-lived sessions like this where it's not straightforward to > reinitialize. There > are any number of reasons why a connection might fail (this is especially > true with TLS where any error in the TCP data will cause TLS connection > failure) and so you want to be able to recover gracefully from those. Once > you have that kind of graceful recovery mechanism, it seems like it would > be straightforward to use that for certificate expiry; even with the new > rules > we're talking weeks of uptime before the certificate expires. > > -Ekr > > >> Cheers, >> -Tiru >> >> On Sat, 21 Jun 2025 at 06:13, Eric Rescorla <e...@rtfm.com> wrote: >> >>> Hi Rifaat, >>> >>> I'm obviously excited to see people encrypting massive amounts of >>> traffic, but I did want to pressure test this use case a bit. >>> >>> I have two questions: >>> >>> 1. What's the mean time between failure of these connections? >>> 2. What do you do if the connection fails? Do you have some way to >>> cleanly restart? >>> >>> Thanks, >>> -Ekr >>> >>> >>> >>> On Fri, Jun 20, 2025 at 5:31 PM Rifaat Shekh-Yusef < >>> rifaat.s.i...@gmail.com> wrote: >>> >>>> We have a use case where optical systems establish a persistent TLS >>>> channel that is then used to mint keys used to encrypt massive amounts of >>>> traffic over fiber optic lines. >>>> This mechanism could be useful to allow the systems to maintain that >>>> TLS channel during certificate rotation, without tearing down the >>>> connection. >>>> >>>> Regards, >>>> Rifaat >>>> >>>> >>>> On Fri, Jun 20, 2025 at 6:55 PM Yaroslav Rosomakho <yrosomakho= >>>> 40zscaler....@dmarc.ietf.org> wrote: >>>> >>>>> I don't believe certificates expire just because of key compromise. >>>>> Hosts could be decommissioned, domains could be repossessed, services >>>>> could >>>>> move around. Certificate Update provides assurance that the peer still has >>>>> the right to claim original identity. >>>>> Let's say an IoT device established a session with a vendor server to >>>>> stream sensitive diagnostic data. The vendor could change server hosting >>>>> provider, update DNS records but forget to shut down the previous >>>>> instance. >>>>> Established connections will stay up though the server effectively lost >>>>> its >>>>> identity. Sadly, these things do happen in the wild. >>>>> >>>>> As of key compromise, there are two separate risks: >>>>> - compromised private key of certificate >>>>> - compromised session key >>>>> >>>>> A Certificate with a potentially compromised private key needs to be >>>>> revoked and replaced with a fresh one. However, rekey of the session (Key >>>>> Update or Extended Key Update) does not bring assurance that the >>>>> connection >>>>> is established with the correct peer - it could well be an imposter in >>>>> possession of a stolen private key. Certificate Update provides that >>>>> assurance. >>>>> >>>>> Extended Key Update is about reducing risks associated with the >>>>> compromised session key. >>>>> >>>>> Best Regards, >>>>> Yaroslav >>>>> >>>>> On Fri, Jun 20, 2025 at 11:29 PM Watson Ladd <watsonbl...@gmail.com> >>>>> wrote: >>>>> >>>>>> On Fri, Jun 20, 2025 at 3:20 PM Yaroslav Rosomakho >>>>>> <yrosoma...@zscaler.com> wrote: >>>>>> > >>>>>> > Hello Watson, >>>>>> > >>>>>> > On Fri, Jun 20, 2025 at 10:50 PM Watson Ladd <watsonbl...@gmail.com> >>>>>> wrote: >>>>>> >> >>>>>> >> >>>>>> >> What exactly is the rationale here? Do we expect that identies >>>>>> >> actually change when a certificate expires? >>>>>> > >>>>>> > >>>>>> > Certificate confirms identity information for a certain period of >>>>>> validity as long as it is not revoked. Communication with an endpoint >>>>>> that >>>>>> produces a revoked or expired certificate is deemed to have unacceptable >>>>>> risk and typically denied. However, this risk applies to established >>>>>> sessions in exactly the same way as it applies to new sessions. The >>>>>> rationale is to ensure that the peer identity is still valid by the time >>>>>> the original certificate expired or got revoked. >>>>>> >>>>>> Certificate expiry is in some sense driven by the risk of key >>>>>> compromise. If the key is compromised it fails to provide assurance as >>>>>> to the identity of the counterparty. But that compromise could also >>>>>> happen to the keys protecting the session over that length of time >>>>>> (yes, there are some differences in threat model depending on how they >>>>>> are stored). In that case this draft doesn't actually protect >>>>>> anything: an attacker with those keys is able to see the traffic going >>>>>> through and continue to exploit the session. >>>>>> >>>>>> This isn't really a problem of identities expering (how could they) >>>>>> but rather risk limitation. >>>>>> >>>>>> The reason I belabor this point is the conclusion: we have to rekey >>>>>> the connection as well to get the assurances we want. The mechanism >>>>>> here doesn't do that. >>>>>> >>>>>> > >>>>>> > TLS 1.2 and prior could perform re-key and re-authentication >>>>>> through rehandshake. As the very generic rehandshake carried unacceptable >>>>>> security risks it was removed in TLS 1.3. Extended Key Update brings back >>>>>> re-key in a secure way. Similarly, Certificate Update proposal is >>>>>> intended >>>>>> to bring back re-authentication in a very limited controlled fashion. >>>>>> > >>>>>> > Best Regards, >>>>>> > Yaroslav >>>>>> > >>>>>> > >>>>>> > 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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Astra mortemque praestare gradatim >>>>>> >>>>> >>>>> >>>>> 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 >>> >> -- 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
