[TLS] Re: [External⚠️] Re: Certificate Update in TLS

[Watson Ladd <[e-mail]>]

On Sun, Jun 22, 2025, 5:14 AM Yaroslav Rosomakho <yrosomakho=
[e-mail]> wrote:

> 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.
>

Why can't you spin up the new session, move the traffic and then tear down
the old one?

>
>
> Best Regards,
> Yaroslav
>
> On Sun, Jun 22, 2025 at 4:37 AM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Sat, Jun 21, 2025 at 4:05 AM tirumal reddy <[e-mail]> 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-mail]> 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 <
>>>> [e-mail]> 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=
>>>>> [e-mail]> 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 <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> On Fri, Jun 20, 2025 at 3:20 PM Yaroslav Rosomakho
>>>>>>> <[e-mail]> wrote:
>>>>>>> >
>>>>>>> > Hello Watson,
>>>>>>> >
>>>>>>> > On Fri, Jun 20, 2025 at 10:50 PM Watson Ladd <
>>>>>>> [e-mail]> 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 -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>> _______________________________________________
>>>>> TLS mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>> _______________________________________________
>>>> TLS mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>