Hi Ekr, I do not know the answer to the first question; I will have to get back to you on that.
With regards to the second question: yes, we maintain a number of keys that we use to encrypt data on the optical lines, to allow us to recover from such failures. Is this mechanism essential for our use case: the answer is no; that is the reason I mentioned that it "could be useful" in my initial message. I see it as an optimization to avoid tearing down the connection during certificate rotation. Regards, Rifaat On Fri, Jun 20, 2025 at 8:43 PM 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
