Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

From: John Mattsson <[email-masked]>
Date: Fri, 5 Mar 2021 17:01:04 +0000

Hi,

I asked a very similar question a couple of weeks ago. Good to know that other people have similar problems.
https://mailarchive.ietf.org/arch/msg/tls/bo-_9gbNqNAlyzs2Opv16hLwt2k/

Cheers,
John

-----Original Message-----
From: TLS <[email-masked]> on behalf of "Fries, Steffen" <[email-masked]>
Date: Friday, 5 March 2021 at 15:02
To: "[email-masked]" <[email-masked]>
Subject: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Hello all

I've got a question regarding application of TLS 1.3 to protect long lasting  connections. Specifically on the trigger to perform a revocation check for the utilized certificates in the handshake. 

The background is that for the securing TCP based communication in power system automation we defined the application of TLS in IEC 62351-3. The document specifies how to use TLS v1.2 in this environment. As some of the connections are rather long lasting connections, the document defines the usage of TLS session renegotiation at least every 24 hours to update the session key material on one hand and to enforce the certificate verification from both sides (TLS is always used with mutual authentication) including the revocation check. The 24 hours were motivated by an expected CRL update once a day. 

As TLS 1.3 is available the consequent next step is the consideration also for power system automation. In TLS 1.3 session renegotiation is not available anymore. The session key update can easily be addressed by the post-handshake messages. For performing a certificate based authentication during the session I understood one could use the post-handshake authentication approach. But this seems to be available only for a client side authentication. Is there any option in TLS to also enforce a server side authentication during an ongoing session?  Again, the reason for a certificate based authentication is to have a trigger for the revocation check of the certificates used in the initial handshake. If post-handshake certificate based authentication is not supported in TLS 1.3, it would require to have a separate mechanism/process that checks the revocation state of the certificates utilized in the initial handshake. 

Hence the question if there is a feature in TLS 1.3, which would provide the functionality to invoke a mutual certificate based authentication.

Best regards
Steffen

--
Steffen Fries
Siemens AG

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 5 Mar 2021 17:06:21 +0000

The TLS WG has not addressed long-lived connections. Probably because most of the people who developed the spec are in the Web space. That's not intended as a criticism, just pointing out where there seems to be this blind spot.

AFAIK, nothing stops either side from periodically going off on its own to verify the peer identity and then sending an alert to shut things down.  That might not scale well, and some kind of extension that allows both sides to send updated status information might be useful and I would support that. (Peter Gutman, you still around? :)

---

From: Nico Williams <[email-masked]>
Date: Fri, 5 Mar 2021 11:35:17 -0600

On Fri, Mar 05, 2021 at 05:01:04PM +0000, John Mattsson wrote:
> On Friday, 5 March 2021 at 15:02, Fries, Steffen wrote:
> > I've got a question regarding application of TLS 1.3 to protect long
> > lasting  connections. Specifically on the trigger to perform a
> > revocation check for the utilized certificates in the handshake. 

You can perform OCSP or CRL checks on the RPs at any time.  You don't
need a protocol trigger for it.  You can use a timer.

The issue is that the EE certificate (or intermediates in the chain
perhaps) could expire or be replaced before the connection ends, and
then you might want the EE to present a new certificate and, if for a
new key, then also a proof of possession.  One could use session
renegotiation back when it existed, but it does not now.

> > Hence the question if there is a feature in TLS 1.3, which would
> > provide the functionality to invoke a mutual certificate based
> > authentication.

While renegotiation will never be re-added, there is post-handshake
authentication (RFC 8446, section 4.6.2), and while that is currently
about authenticating the _client_ to the server, it should be trivial to
extend the protocol to support re-authenticating the server to the
client as well.

Authenticating the client to the server and vice-versa would be
independent, at least when using certificates, though not so much when
using PSK.  Each relying party would send a CertificateRequest message
on a timer based on local configuration of certificate freshness policy
and/or the peer's certificate's expiration time, or whatever you like.

Nico
--

---

From: John Mattsson <[email-masked]>
Date: Fri, 5 Mar 2021 18:42:40 +0000

>extend the protocol to support re-authenticating the server to the

I think the current Post-Handshake authentication is not really suitable for long-term connections. It assures that the other party is still alive but it does not shut out any other third parties with access to application_traffic_secret_N. Such parties may have gotten the key with or without collaboration with one of the nodes.

Agree that the negotiation part of renegotiation should not come back. Below is a sketch of what I think would be needed Post-Handshake for DTLS/SCTP with DTLS 1.3:

       {KeyShareEntry}         -------->
                                              {KeyShareEntry}
                                          {CertificateVerify}  
                               <--------           {Finished}  
       {CertificateVerify}
       {Finished}              -------->

               Derive-Secret( ... ) = exporter_secret_N

Cheers,
John

-----Original Message-----
From: Nico Williams <[email-masked]>
Date: Friday, 5 March 2021 at 18:35
To: John Mattsson <[email-masked]>
Cc: "Fries, Steffen" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 5 Mar 2021 13:35:02 -0600

On Fri, Mar 05, 2021 at 06:42:40PM +0000, John Mattsson wrote:
> I think the current Post-Handshake authentication is not really
> suitable for long-term connections. It assures that the other party is
> still alive but it does not shut out any other third parties with
> access to application_traffic_secret_N. Such parties may have gotten
> the key with or without collaboration with one of the nodes.

We assume local security, so the only way the TLS keys could have leaked
to third parties is if either a) the local security assumption fails, in
which case you have bigger problems, or b) the cryptographic security of
TLS itself failed, in which case you have bigger problems, or c) you're
exceeding usage limits on a symmetric cipher.

Changing session keys wouldn't help you in cases (a) or (b).

I think the only interesting case is (c).  If you're using a 128-bit
block cipher, you're not in case (c) as you'd have to transfer something
like 2PB before you exceed AES key usage limits.

At some point you have to be prepared to reconnect.  Application
protocols that work like BGP (destroy the world on RST) simply need
to be fixed to not do that.

> Agree that the negotiation part of renegotiation should not come back.
> Below is a sketch of what I think would be needed Post-Handshake for

That's essentially renego-lite.  Note that there's protocol timing
trickiness in getting this right.  SSHv2, which does have proper
re-keying, has experience with that.

> DTLS/SCTP with DTLS 1.3:

What's special about DTLS vs. TLS?  Why should one get this but not the
other?

Nico
--

---

From: Watson Ladd <[email-masked]>
Date: Fri, 5 Mar 2021 11:37:46 -0800

> I think the current Post-Handshake authentication is not really suitable for long-term connections. It assures that the other party is still alive but it does not shut out any other third parties w…

The application traffic secret N+1 and the security of the
authentication is unaffected by compromise of key N AFAIK. I'm not
sure what property you want here that is stronger.
Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Mar 2021 16:46:15 -0800

On Fri, Mar 5, 2021 at 11:38 AM Watson Ladd <[email-masked]> wrote:

> > I think the current Post-Handshake authentication is not really suitable
> for long-term connections. It assures that the other party is still alive
> but it does not shut out any other third parties with access to
> application_traffic_secret_N. Such parties may have gotten the key with or
> without collaboration with one of the nodes.
>

It seems to me that there are potentially two distinct properties here:

1. Post-Compromise Security in the case where the traffic keys were leaked
2. Re-authentication of the server.

Id like to understand the second use case better.

Assume that Alice connects to Bob and Bob authenticates with certificate X
which is valid at the time. As long as Bob's certificate remains valid, I'm
not sure that any new TLS behavior is required. I.e., Alice is free to
re-validate the certificate (i.e., check for revocation) but it's not clear
to me that as long as it is valid, it is necessary for Bob to re-prove
possession of the key. The primary threat that the defends against is an
un-detected temporary misuse of Bob's key at a prior time, which seems
distinct from future compromise. So, it seems like you can just re-validate
the key and then abort the connection if that fails, as Rich Salz suggests.

This leaves us with the case where Bob's certificate is no longer valid but
Bob has a new certificate [0]. In this case, just re-validating does not
help. Does that happen so often that we need protocol machinery other than
just tearing down the connection and starting over?

-Ekr

[0] Potentially, with a different key, though just assuming that because
the key is the same you can transplant the new identity on seems dangerous,
as we usually want to sign over the identities.

---

From: Nico Williams <[email-masked]>
Date: Sat, 6 Mar 2021 00:11:25 -0600

> just tearing down the connection and starting over?

Probably not.  I've seen 5 day server certificates in use.  And while
it's possible to keep connections open that long or longer, as Viktor
points out, if you do keep a connection open and active longer than that
and the server is still there (i.e., some node has its address and the
connection's traffic keys), then that's probably good enough evidence
that the server is still valid and still would have a fresh cert if you
were to reconnect to it.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 6 Mar 2021 01:21:14 -0500

> that the server is still valid and still would have a fresh cert if you

In general, I think breaking an established connection just to
reauthenticate the server only needlessly risks occasionally finding an
expired certificate that someone forgot to renew.  Server certificates
good at time of connection establishment should, barring extraordinary
circumstances be good for the life of the connection.

I suspect that in at least some cases the motivation to revalidate the
server certificate is only requested because it could be done in
principle, and ticks some checkbox about using CRLs, because they
exist, rather than from a clear threat this addresses.

However, it is possible that there actually exist use-cases where this
makes some sense, and that case, If connection lifetimes would otherwise
last unacceptably long, make a new connection, and close the old (in
some appropriate order).

-- 
    Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 6 Mar 2021 06:55:52 +0000

Nico Williams <[email-masked]> writes:

>I've seen 5 day server certificates in use.  

For IEC-62351 work you're far more likely to see certificates issued with an
expiry date of never, because the last thing you want is your power grid to be
taken offline due to a cert someone forgot to renew.

In terms of CRL updates the situation is similar, the spec may say you need to
check once every X time interval but in practice you forget to perform the
check in case it takes your grid offline.  Or set a flag saying "cert revoked"
and continue anyway, I've seen both.  The 24-hour thing sounds like someone's
checkbox requirement rather than anything practically useful, or usable.

Peter.

---

From: Nico Williams <[email-masked]>
Date: Sat, 6 Mar 2021 15:10:37 -0600

> taken offline due to a cert someone forgot to renew.

When expirations are short, you will not forget to renew.  That's part
of the point of short-lived certificates.

Set lifetime long enough that you have enough time to renew in most
outage scenarios (i.e., pick N days such that you expect no outage will
take longer than that to resolve, and be conservative for things like
power grids), but short enough that you simply must automate renewal.

> and continue anyway, I've seen both.  [...]

Sure.

>                               [...].  The 24-hour thing sounds like someone's

Short-lived certs are a "checkbox requirement" where the theory is that
if it's short enough (doesn't have to be 1 day) then you will be forced
to automate renewal, so you'll never fail to renew.

It's about improving ops, not so much about security.

That it also helps with revocation -so you don't have to bother with it-
is also an ops (and dev) benefit.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 6 Mar 2021 15:12:44 -0600

> exist, rather than from a clear threat this addresses.

I agree.  There's no need.

> last unacceptably long, make a new connection, and close the old (in

Yeah, but then, in 2021 BGP still depends on long-lived connections...

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 7 Mar 2021 08:07:48 +0000

Nico raised some really good points here.

I think it is useful to start with the problem description.

It seems that you are concerned that there is a possibility for leakage or compromise of keying material during the lifetime of the session.
What could happen?

* Long-term keys*,
* Some keys used in the key hierarchy,
* keys used for protecting the application traffic

Additionally, you could also consider the case that the trust anchor store gets compromised.

In any case, you seem to be concerned about the leakage of long-term keys (at least that's what I get from the email thread).

If your long-term keys got compromised then you have a serious problem. Re-running even the full handshake will not indicate problem. It will just work fine.

You will somehow have to find out that these long-term keys have been leaked, which will not be easy. Then, you need to isolate the endpoints using those compromised keys and reprovision new keys to them. You might want to terminate ongoing connections as well. Since you will often not know what exactly has been compromised (at least not quickly enough), you might need to take a range of steps to re-set it to a known good state (such as doing a firmware update, in case of an IoT device).

Many of these aspects are, however, outside the scope of TLS itself.

Could you elaborate on the threats you are trying to address?

Ciao
Hannes

*: Often a device has more than one long-term key pair (used for different purposes). Without further complicating things, the impact depend a bit on which keys have been leaked.

-----Original Message-----
From: TLS <[email-masked]> On Behalf Of Nico Williams
Sent: Friday, March 5, 2021 8:35 PM
To: John Mattsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 05, 2021 at 06:42:40PM +0000, John Mattsson wrote:
> >about authenticating the _client_ to the server, it should be trivial
> >to extend the protocol to support re-authenticating the server to the
> >client as well.
>

We assume local security, so the only way the TLS keys could have leaked to third parties is if either a) the local security assumption fails, in which case you have bigger problems, or b) the cryptographic security of TLS itself failed, in which case you have bigger problems, or c) you're exceeding usage limits on a symmetric cipher.

I think the only interesting case is (c).  If you're using a 128-bit block cipher, you're not in case (c) as you'd have to transfer something like 2PB before you exceed AES key usage limits.

At some point you have to be prepared to reconnect.  Application protocols that work like BGP (destroy the world on RST) simply need to be fixed to not do that.

> Below is a sketch of what I think would be needed Post-Handshake for

That's essentially renego-lite.  Note that there's protocol timing trickiness in getting this right.  SSHv2, which does have proper re-keying, has experience with that.

> DTLS/SCTP with DTLS 1.3:

What's special about DTLS vs. TLS?  Why should one get this but not the other?

Nico
--

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 7 Mar 2021 09:57:40 +0000

Nico Williams <[email-masked]> writes:

>When expirations are short, you will not forget to renew.  That's part of the
>point of short-lived certificates.

So instead of getting one chance a year for your control system to break
itself if the renewal fails, you get hundreds of them?

Peter.

---

From: Graham Bartlett <[email-masked]>
Date: Sun, 7 Mar 2021 11:15:31 +0000

Hi

I have a fair amount of hands on experience with IPsec VPNs, and many
organisations look to use TLS in a similar manner.

To give you an example of where you might look to perform a regular
revocation check on long lived connections;

Solution with many remote devices (think remote access, so phones, laptops,
IoT devices etc)
A remote device is compromised, on the gateway there could be 1000s of
devices connected.
I've found that most vendor solutions aren't geared up for an admin to
easily determine the compromised device and prevent this reconnecting. Most
organisations have a disconnect between the SOC, PKI team and the team that
manages the remote access gateway, getting a process that'll involve all 3
teams usually doesn't work.

I've found that the best method to prevent the device from connecting is
for the certificate to be revoked, the CRL refreshed and then a
re-authentication performed on all active connections.

I'm not as familiar with TLS as I am IPsec, but hope that this explains
a scenario where I feel re-authentication would be very valuable.

cheers

---

From: Deb Cooley <[email-masked]>
Date: Sun, 7 Mar 2021 06:52:42 -0500

So we can break this down into 2 categories:

expiry
revocation

for both clients and servers.

Expiry:  for the server/client.  I suspect this is mostly a 'don't care',
except in the case where a certificate *should* be revoked after it is
expired (nobody does that, right?).  Is this worth addressing?  I suspect
not.

Revocation:  The RP* can check this whenever it desires.  If one has
designed a long lived connection, then the RP needs to handle it.  Does
TLS, the protocol need to handle it?  Don't know.

Short lived certificates:  I think these are a good idea.  And if one does
this, rekey/renewal early and often is the way to prevent breakage.
IMHO....

On Sun, Mar 7, 2021 at 6:16 AM Graham Bartlett <[email-masked]>
wrote:

> Solution with many remote devices (think remote access, so phones,
> laptops, IoT devices etc)

---

From: Graham Bartlett <[email-masked]>
Date: Sun, 7 Mar 2021 12:15:24 +0000

Hi

Ref

'Expiry:  for the server/client.  I suspect this is mostly a 'don't care',
except in the case where a certificate *should* be revoked after it is
expired (nobody does that, right?).  Is this worth addressing?  I suspect
not.'

I would imagine that the implementation would pull the session down once
the certificate expires, so the session only lasts for the lifetime of the
certificate.

I know that some IPsec implementation does this.

cheers

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 7 Mar 2021 15:50:43 +0000

Focusing on one sentence from below:

  *   I've found that the best method to prevent the device from connecting is for the certificate to be revoked, the CRL refreshed and then a re-authentication performed on all active connections.

Why would you trigger re-authentication of all connections? You could terminate the connection of the device with the compromised certificate.

In your IPSec VPN scenario, how do you get a new certificate to the compromised device?

Ciao
Hannes

From: TLS <[email-masked]> On Behalf Of Graham Bartlett
Sent: Sunday, March 7, 2021 12:16 PM
To: Peter Gutmann <[email-masked]>
Cc: John Mattsson <john.mattsson=[email-masked]>; TLS List <[email-masked]>
Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

Hi

I have a fair amount of hands on experience with IPsec VPNs, and many organisations look to use TLS in a similar manner.

To give you an example of where you might look to perform a regular revocation check on long lived connections;

Solution with many remote devices (think remote access, so phones, laptops, IoT devices etc)
A remote device is compromised, on the gateway there could be 1000s of devices connected.
I've found that most vendor solutions aren't geared up for an admin to easily determine the compromised device and prevent this reconnecting. Most organisations have a disconnect between the SOC, PKI team and the team that manages the remote access gateway, getting a process that'll involve all 3 teams usually doesn't work.

I've found that the best method to prevent the device from connecting is for the certificate to be revoked, the CRL refreshed and then a re-authentication performed on all active connections.

I'm not as familiar with TLS as I am IPsec, but hope that this explains a scenario where I feel re-authentication would be very valuable.

cheers

On Sun, Mar 7, 2021 at 9:58 AM Peter Gutmann <[email-masked]<mailto:[email-masked]>> wrote:

Peter.

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 7 Mar 2021 15:50:51 +0000

Graham, Deb,

  *   'Expiry:  for the server/client.  I suspect this is mostly a 'don't care', except in the case where a certificate *should* be revoked after it is expired (nobody does that, right?).  Is this worth addressing?  I suspect not.'

I agree.

  *   I would imagine that the implementation would pull the session down once the certificate expires, so the session only lasts for the lifetime of the certificate.

Agree. I guess this case rarely happens because short-lived certificates are not so short lived after all.

  *   Revocation:  The RP* can check this whenever it desires.  If one has designed a long lived connection, then the RP needs to handle it.  Does TLS, the protocol need to handle it?  Don't know.

I don’t see a need for TLS to do something.

  *   Short lived certificates:  I think these are a good idea.  And if one does this, rekey/renewal early and often is the way to prevent breakage.  IMHO....

I would imagine that the change of certificate will trigger a new handshake. If only the client-side certificate changes on a regular basis then I could imagine the Post handshake authentication to be quite useful.

Ciao
Hannes

On Sun, Mar 7, 2021 at 11:53 AM Deb Cooley <[email-masked]<mailto:[email-masked]>> wrote:
So we can break this down into 2 categories:

expiry
revocation

Expiry:  for the server/client.  I suspect this is mostly a 'don't care', except in the case where a certificate *should* be revoked after it is expired (nobody does that, right?).  Is this worth addressing?  I suspect not.

Revocation:  The RP* can check this whenever it desires.  If one has designed a long lived connection, then the RP needs to handle it.  Does TLS, the protocol need to handle it?  Don't know.

Short lived certificates:  I think these are a good idea.  And if one does this, rekey/renewal early and often is the way to prevent breakage.  IMHO....

On Sun, Mar 7, 2021 at 6:16 AM Graham Bartlett <[email-masked]<mailto:[email-masked]>> wrote:
Hi

cheers

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 7 Mar 2021 08:25:01 -0800

> the certificate expires, so the session only lasts for the lifetime of the

Many people expect this, but I don't think there's universal agreement
that it's the right behavior.  The divide between authentication and
authorization that (IIRC) Viktor called out is relevant here -- the
initial key exchange and, to large extent, authentication, do not suddenly
become invalid upon credential expiry, but any authorization derived from
the credential might.  So it seems that whether the session should terminate
at the certificate expiry time is rather dependent on what the session is
being used for.

-Ben

---

From: Graham Bartlett <[email-masked]>
Date: Sun, 7 Mar 2021 19:22:24 +0000

Hi Hannes

You're right, I rushed the answer. You would only need to perform the CRL
check on all existing connections, not re-authenticate. This would then
kill the session for the recently revoked certificate.

So I've mainly worked on solutions involving mobile devices; laptops and
phones. Normally if the device is lost/stolen it's gone and assumed
compromised. You wont be issuing it a new certificate for that device.

cheers

On Sun, Mar 7, 2021 at 3:50 PM Hannes Tschofenig <[email-masked]>
wrote:

>    - I've found that the best method to prevent the device from
>    connecting is for the certificate to be revoked, the CRL refreshed and then
>    a re-authentication performed on all active connections.
>
>
>
> Why would you trigger re-authentication of all connections? You could
> terminate the connection of the device with the compromised certificate.
>
>
>
> *From:* TLS <[email-masked]> *On Behalf Of * Graham Bartlett
> *Sent:* Sunday, March 7, 2021 12:16 PM
> *To:* Peter Gutmann <[email-masked]>
> *Cc:* John Mattsson <john.mattsson=[email-masked]>; TLS
> List <[email-masked]>
> *Subject:* Re: [TLS] Question to TLS 1.3 and certificate revocation
> checks in long lasting connections
>
>
>
> Hi
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Nico Williams <[email-masked]>
Date: Sun, 7 Mar 2021 16:35:35 -0600

On Sun, Mar 07, 2021 at 09:57:40AM +0000, Peter Gutmann wrote:
> > When expirations are short, you will not forget to renew.  That's
> > part of the point of short-lived certificates.
> 

Yes.  Exactly.  It's a human factors problem.  And this solution works.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 7 Mar 2021 23:19:49 +0000

>    Yes.  Exactly.  It's a human factors problem.  And this solution works.

With all due respect, *absolutely not*.
    _______________________________________________
    TLS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/tls

---

From: Nico Williams <[email-masked]>
Date: Sun, 7 Mar 2021 17:41:34 -0600

> With all due respect, *absolutely not*.

I'm not sure what it is you're imagining.  What actually happens in the
cases I'm familiar with is that there is one very long-lived root of
trust (e.g., an endorsement key in a TPM) credential that is used to get
all the short-lived credentials, and this is fully automated.  In some
cases the short-lived credentials are obtained by apps using the host's
credentials, and then only when the application is running but still,
periodically.

The benefits of this arrangement are: a) no need for revocation of
short-lived credentials, b) no need to worry about credential
expiration (because the process is automated).

I've also seen environments with very long-lived credentials where
someone has to remember to renew them.  I've seen lots of failures in
those, but none in the case described above.

Nico
--

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 7 Mar 2021 23:47:45 +0000

I'm not sure what it is you're imagining.  What actually happens in the
    cases I'm familiar with is .  .  .  .  .

Well-put - the point being that the cases you're familiar with do not cover the entire spectrum of use cases. Specifically, they do not match *my* operating environment.

You may claim that my environment does not represent yours. Sure, fine. Similarly, *yours does NOT represent mine*.

And let's dispose with the "you're imagining" crap, shall we? I think we've known each other long enough to be more polite. Otherwise, suit yourself.

---

From: Nico Williams <[email-masked]>
Date: Sun, 7 Mar 2021 17:59:27 -0600

On Sun, Mar 07, 2021 at 11:47:45PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> Well-put - the point being that the cases you're familiar with do not
> cover the entire spectrum of use cases. Specifically, they do not
> match *my* operating environment.
> 
> You may claim that my environment does not represent yours. Sure,
> fine. Similarly, *yours does NOT represent mine*.

I'm not telling you what to do.

> And let's dispose with the "you're imagining" crap, shall we? I think
> we've known each other long enough to be more polite. Otherwise, suit
> yourself.

No offense was meant.  It's reasonable to suspect that even someone I
know and I know is smart may not have all the relevant details.

Besides, your

>>> With all due respect, *absolutely not*.

followed by no explanation, seems like much more likely to be intended
to cause offense than "I'm not sure what it is you're imagining"
followed by an explanation.  I took it at face value however, and
followed up.  What a crime.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 7 Mar 2021 19:05:34 -0500

> With all due respect, *absolutely not*.

Well, it works when fragile manual processes (likely to be entirely
forgotten until things break) that are almost good enough to get by
on every year or two, become plainly unreasonable when exercised every
month or every week.  In other words, short-lived certs force:

    - Active monitoring

    - Automation of preëmptive renewals (with sufficient time
      to retry more than once on failure).

The tools to make this possible need to be available before we ask
people to invent this for themselves, but the effect on operational
discipline is real.

If either monitoring or automation are skipped, then sure, you have
a recipe for failure.  But if the signal is not ignored, and proper
automation is applied, reliability actually improves.

I see this effect in the stability of DANE deployments at domains that
are using Let's Encrypt with "mailinabox.email" which automates the
lifecycle including TLSA record updates, ..., v.s. DYI MTAs with certs
are only renewed every year or two (often wildcard shared by all MTAs
for the domain).

The mailinabox systems do a far better job of keeping their certs valid.
Despite the fact that they make up 1/3 of the deployed MXs, they make up
a much smaller fraction of the domains I ping when the DANE survey finds
poorly managed cert chains that fail authentication.

Does this mean that a nuclear reactor's cooling system should shut down
when a cert expires?  Probably not, ... but if one is going to manage
certificates that do expire, my bet is that the short-lived ones are
better managed, and will exhibit fewer total hours of downtime, despite
the more frequent expirations.

-- 
    Viktor.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 8 Mar 2021 00:08:33 +0000

>    I'm not telling you what to do.

By making a statement "this solution works" without any qualifiers, you essentially are.
The truth is - it works well for *some* environments, including yours. I've some where it would work too.
Unfortunately, I *also* have plenty where it cannot work.

>    . . . . .  It's reasonable to suspect that even someone I

My point is - we *both* may not have all the relevant details about each other's environments. Which is why I absolutely disagreed with your "this solution works" statement. 

>    followed up.  What a crime.

;-) OK, touche.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 8 Mar 2021 03:21:22 +0000

Viktor Dukhovni <[email-masked]> writes:

>But if the signal is not ignored, and proper automation is applied,
>reliability actually improves.

No, it drops.  You're going from a situation where you've eliminated any
chances of outages due to expired certs to one where you get to play Russian
roulette every single day: Will the cert renewal work, or will it fail for
some reason?  Let's spin the cylinder and see if this is the day our grid goes
down.

Even if you somehow create a 100% successful magical process for replacing
certs that never ever fails, you're now introduced another possible failure
situation, with certs changing constantly there's a chance that something that
relies on them can't handle a new cert, for example because an issuing CA has
renewed as well or something similar.

It's just building in more and more opportunities for failure from a mechanism
that's supposed to be making your infrastructure more robust, not less.

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 7 Mar 2021 19:31:24 -0800

Hi Peter,

Just to confirm: the scenario you're using to contrast to the one described
by Viktor (and Nico) is a scenarios in which the certificates expire at "never"
(99991231235959Z)?

I think that at least some people are contrasting against something other
than that...

Thanks,

Ben

On Mon, Mar 08, 2021 at 03:21:22AM +0000, Peter Gutmann wrote:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!GaaCbhUsGvSdgqi6crkwhODrap4fYzdX6pgIOq4zyhG9nX88r3GTRHuFOsw1ew$

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 7 Mar 2021 22:40:33 -0500

> I think that at least some people are contrasting against something other

Correct, I'm contrasting with N-year certs for N <= 30 (longer if
expected lifetime of device is larger, e.g. switches in the NYC subway
system, though their actual deployed lifetime has well exceeded anything
"planned").  In other words, with certs that will actually need to be
replaced now and then.

Peter's "never" scenario has its place, it's the cases that fall between
"never" and short-lived that I find suboptimal.  Do it well, or don't
do it at all.

-- 
    Viktor.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 8 Mar 2021 03:45:16 +0000

Benjamin Kaduk <[email-masked]> writes:

>by Viktor (and Nico) is a scenarios in which the certificates expire at
>"never" (99991231235959Z)?

Not that "never" since it would break a lot of things, but some time far
enough in the future that you don't have to worry about it.  14 January 2038
was one I've seen used, but that was at a point when 2038 was still 20+ years
away and the equipment might have been expected to be EOL'd by then.  Not sure
what's being used now that the time to Y2038 is a lot less than the lifetime
of the equipment.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Mar 2021 01:51:37 -0200

> On Mar 8, 2021, at 1:45 AM, Peter Gutmann <[email-masked]> wrote:
> 
> enough in the future that you don't have to worry about it.

The cert generator I cobbled together for the OpenSSL test-suite
generates 100-year certs.  These work well, and should outlast
the lifetime of the library...  Lord help civilization, if it
is still using C for critical software in ~100 years.

(Before that, some older certs used in the build had in fact expired).

-- 
	Viktor.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 8 Mar 2021 09:15:43 +0100

> On 7 Mar 2021, at 17:25, Benjamin Kaduk <bkaduk=[email-masked]> wrote:
> 

Maybe there’s a need for a BCP here. It is unclear to me how to apply these
discussions to SIP and we have a few points worth noting from this dicussion.

- Describe the dependencies in Benjamins statement above and how
  they apply to protocols
- Open a new session before deciding to close the old one
- Application timers to cert expiry

Seems like something for UTA to me.

/O

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 8 Mar 2021 08:51:31 +0000

Hi,

First of all thanks for all the discussion on that question, which is great input also to the discussion in IEC. 

> From: TLS <[email-masked]> On Behalf Of Hannes Tschofenig
The problem that was addressed so far with the session renegotiation in TLS 1.2 was motivated by different points. 
- Recommendation in RFC 5246 regarding the use of the SessionID  lifetime
- Regular session key update for the ongoing TLS Session
- Trigger to verify the certificates used by both sides on a regular base, ideally in relation to the update of locally available revocation information

For the latter, the assumption was that some of the processes, when a long term key is compromised, may not be perfectly synchronized, meaning that  the entity with a potentially compromised certificate/private key (long term key) is not immediately taken from the network. If the certificate is put onto a CRL , the RP would realize this during the next complete handshake and tear down the connection. An alternative of this could indeed be to utilize an external trigger like whenever the CRL is refreshed (which should happen every 24 hours), the certificates of ongoing connections are validated regarding their status. As this is independent of TLS, it would work also with TLS 1.3.

By comparing, what has been used in TLS 1.2 we simply stumbled about the fact that the trigger to perform the revocation check is no longer available for both sides, client and server. As said, the client could be authenticated using post authentication but not the server. This would mean to solve the problem of identifying a revoked certificate in an ongoing session could be done externally of TLS but the result would be fed back to TLS, if a connection needs to be closed due to a revoked certificate. 

Regards
Steffen

> 
> It seems that you are concerned that there is a possibility for leakage or
> compromise of keying material during the lifetime of the session.
> What could happen?
> 
> * Long-term keys*,
> In any case, you seem to be concerned about the leakage of long-term keys (at
> least that's what I get from the email thread).
> 
> If your long-term keys got compromised then you have a serious problem. Re-
> running even the full handshake will not indicate problem. It will just work fine.
> 
> You will somehow have to find out that these long-term keys have been leaked,
> which will not be easy. Then, you need to isolate the endpoints using those
> compromised keys and reprovision new keys to them. You might want to
> terminate ongoing connections as well. Since you will often not know what
> exactly has been compromised (at least not quickly enough), you might need to
> take a range of steps to re-set it to a known good state (such as doing a
> firmware update, in case of an IoT device).
> 
> *: Often a device has more than one long-term key pair (used for different
> purposes). Without further complicating things, the impact depend a bit on
> which keys have been leaked.
> 
> We assume local security, so the only way the TLS keys could have leaked to
> third parties is if either a) the local security assumption fails, in which case you
> have bigger problems, or b) the cryptographic security of TLS itself failed, in
> which case you have bigger problems, or c) you're exceeding usage limits on a
> symmetric cipher.
> 
> I think the only interesting case is (c).  If you're using a 128-bit block cipher,
> you're not in case (c) as you'd have to transfer something like 2PB before you
> exceed AES key usage limits.
> 
> At some point you have to be prepared to reconnect.  Application protocols that
> work like BGP (destroy the world on RST) simply need to be fixed to not do that.
> 
> That's essentially renego-lite.  Note that there's protocol timing trickiness in
> getting this right.  SSHv2, which does have proper re-keying, has experience with
> that.
> 
> > DTLS/SCTP with DTLS 1.3:
> 
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 8 Mar 2021 11:58:48 +0000

Peter can certainly speak for himself :) but I don't think it's never.

I think it's also the kind of thing where someone does things manually, and then goes out into the field for a service operation.  So not just never, but also situations where automation isn't appropriate and installing software bits is like maintaining hardware blobs.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Mar 2021 13:04:59 -0500

On Mon, Mar 08, 2021 at 08:51:31AM +0000, Fries, Steffen wrote:

> - Trigger to verify the certificates used by both sides on a regular
>   base, ideally in relation to the update of locally available
>   revocation information
> 
> For the latter, the assumption was that some of the processes, when a
> long term key is compromised, may not be perfectly synchronized,
> meaning that the entity with a potentially compromised
> certificate/private key (long term key) is not immediately taken from
> the network.

So it sounds like the concern is that the key may have already been
compromised at the time the session was established, but was not yet
published on a CRL?  And so you want to keep checking the CRL
periodically, in case the client is talking to an MiTM attacker,
and it isn't too late to undo the damage.

Now of course the client can just check its CRL any time it wants,
without redoing the handshake.  It typically has (or can arrange to
retain) the server's certificate chain from the initial handshake.

So the only case that comes to mind where a new handshake is needed to
refresh the certificate validity is with stapled OCSP, where the server
is the source of the certificate freshness data.

My take is such measures are much too complicated.  Just keep the
connection lifetime short, and make a new one from time to time.  Also
keep certificate lifetimes short.  Where DNSSEC is an option on both
ends, you can also use DANE TLSA records instead of CRLs, just publish a
"1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the
server's public key, and give it a short-enough TTL that it can be
replaced quickly.  Presto-magic, no need for OCSP, CRLs, ...

-- 
    Viktor.

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 9 Mar 2021 07:28:26 +0000

> From: TLS <[email-masked]> On Behalf Of Viktor Dukhovni, Sent: Montag, 8. März 2021 19:05
> compromised at the time the session was established, but was not yet published
> on a CRL?  And so you want to keep checking the CRL periodically, in case the
> client is talking to an MiTM attacker, and it isn't too late to undo the damage.
Yes, that would be one scenario. 

> 
> Now of course the client can just check its CRL any time it wants, without
> redoing the handshake.  It typically has (or can arrange to
True, which requires either a timer to do the checks periodically (either using CRL or OCSP) or a trigger when a new CRL is locally available.
So I already gathered, that this may be the solution.

> refresh the certificate validity is with stapled OCSP, where the server is the
> source of the certificate freshness data.
Agree. This would be the case, in which the receiver may have no access to an OCSP responder.

> 
> My take is such measures are much too complicated.  Just keep the connection
> lifetime short, and make a new one from time to time.  Also keep certificate
> lifetimes short.  Where DNSSEC is an option on both ends, you can also use
> DANE TLSA records instead of CRLs, just publish a
> "1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the server's
> public key, and give it a short-enough TTL that it can be replaced quickly.
> Presto-magic, no need for OCSP, CRLs, ...
While this may be a solution in general, it may not fit for power systems (like a substation). 
The application of DNSSEC or DANE is not very common and may not be used. Also due to 
Existing deployments, which do not feature these services (yet). 

Regards
Steffen

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 9 Mar 2021 02:45:07 -0500

> Existing deployments, which do not feature these services (yet). 

I am not trying to suggest that DANE is currently a mainstream option
outside of SMTP (primarily in Northern and Central Europe for now, with
some signs of life in the USA, Canada and Brazil).  The above was more
of an aside for the record.  DANE may be a more realistic choice a few
years from now.  DNSSEC adoption is starting to grow faster, and if this
continues and accelerates, DANE may become more common, time will tell.

Early adopters can of course choose to use it now, but it is far from
mainstream today.

-- 
    Viktor.

---

From: Jonathan Hoyland <[email-masked]>
Date: Wed, 10 Mar 2021 23:30:39 +0000

One option that I haven't seen mentioned in the thread is Exported
Authenticators
<https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14>.

EAs let you send a certificate from either side of the connection at any
point after the handshake is complete.

I'm not sure what the behaviour is if the certificate itself is expired at
the time the EA was sent, but valid at the time the connection was
established, but I'm sure that could be nailed down.

Would something like the client (and equivalently the server) requesting an
EA every 24 hours and hard failing if it didn't get one meet your needs?

Regards,

Jonathan

On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni <[email-masked]> wrote:

> connection
> server's

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 11 Mar 2021 12:30:51 +0000

> From: Jonathan Hoyland <[email-masked]> 
> Sent: Donnerstag, 11. März 2021 00:31
> One option that I haven't seen mentioned in the thread is https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14.
Thank you for the pointer to the draft. 

> EAs let you send a certificate from either side of the connection at any point after the handshake is complete. 
> I'm not sure what the behaviour is if the certificate itself is expired at the time the EA was sent, but valid at the time the connection was established, but I'm sure that could be nailed down.
> Would something like the client (and equivalently the server) requesting an EA every 24 hours and hard failing if it didn't get one meet your needs?
It may help here. From an integration standpoint it is important that the same certificate would be used with EA as used in the handshake to ensure the one used to authenticate in the first place would be verified. That may mean that one would have to store the initially used certificate or at least the fingerprint or serial number and issuer to be able to request the right one in the authenticator request. 
This would be handled on application layer if I understood it right. As the goal would be to have a trigger to verify the certificate against a (new) CRL, the approach of having a timer or a trigger by the newly arrived CRL may be more suitable. But I will have a closer look.

Best regards
Steffen

> Jonathan

On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni <mailto:[email-masked]> wrote:

-- 
    Viktor.

mailto:[email-masked]

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 12 Mar 2021 11:00:23 +0000

Hi Jonathan,

Maybe a further question to the draft you referenced (exported authenticators). Is there a way to request a distinct certificate in the AuthenticatorRequest? Can I ask for the certificates used in the initial handshake from both sides? I saw in the extension that in the ClientCertificateRequest that the server_name may be provided as extension but this may not be sufficient.

Best regards
Steffen

> From: TLS <[email-masked]> On Behalf Of Fries, Steffen (T RDA CST)
> Sent: Donnerstag, 11. März 2021 13:31
> > One option that I haven't seen mentioned in the thread is
> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-14.
> > I'm not sure what the behaviour is if the certificate itself is expired at the time
> the EA was sent, but valid at the time the connection was established, but I'm
> sure that could be nailed down.
> > Would something like the client (and equivalently the server) requesting an EA
> every 24 hours and hard failing if it didn't get one meet your needs?
> It may help here. From an integration standpoint it is important that the same
> certificate would be used with EA as used in the handshake to ensure the one
> used to authenticate in the first place would be verified. That may mean that
> one would have to store the initially used certificate or at least the fingerprint or
> serial number and issuer to be able to request the right one in the authenticator
> request.
> This would be handled on application layer if I understood it right. As the goal
> would be to have a trigger to verify the certificate against a (new) CRL, the
> approach of having a timer or a trigger by the newly arrived CRL may be more
> suitable. But I will have a closer look.
> 
> Best regards
> Steffen
> 
> > Regards,
> 
> > Jonathan
>

---

From: Jonathan Hoyland <[email-masked]>
Date: Fri, 12 Mar 2021 11:40:12 +0000

I don't believe so, but that would seem like a configuration issue.

I guess if you really wanted you could define an extension that goes in the
Certificate Request message (which the AR is based on), assuming there
isn't one already, that requests a specific serial number.
Although that of course makes the system completely brittle if that
certificate gets revoked, expires, or even just becomes unavailable because
of disk failure.
It would be great to see all the potential use cases broken down so the
best solutions can be considered.

Regards,

Jonathan

On Fri, 12 Mar 2021 at 11:00, Fries, Steffen <[email-masked]>
wrote:

> Hi Jonathan,
>
> Maybe a further question to the draft you referenced (exported
> authenticators). Is there a way to request a distinct certificate in the
> AuthenticatorRequest? Can I ask for the certificates used in the initial
> handshake from both sides? I saw in the extension that in the
> ClientCertificateRequest that the server_name may be provided as extension
> but this may not be sufficient.
>
> Best regards
> Steffen
>
> > > EAs let you send a certificate from either side of the connection at
> any point
> > after the handshake is complete.
> > On Tue, 9 Mar 2021 at 07:45, Viktor Dukhovni <mailto:
> [email-masked]>
> > wrote:
> > > While this may be a solution in general, it may not fit for power
> systems (like a
> > substation).
> > > The application of DNSSEC or DANE is not very common and may not be
> used.
> > Also due to