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
