Subject: [Uta] Long connections, forward secrecy, and key exfiltration, certificate lifetimes, exporter_secret

From: John Mattsson <[email-masked]>
Date: Sun, 14 Nov 2021 08:27:25 +0000

Hi,

I promised to send some information to the list regarding security considerations for long connections. I think the (D)TLS 1.3 is lacking considerations on this as well so I made an issue for RFC8446bis.

https://github.com/tlswg/tls13-spec/issues/1245

The info in the issue is probably a good start, draft-ietf-uta-tls13-iot-profile would need to add IoT specific considerations. TLS for constrained IoT is different from TLS for a 100 Gbps interface.

Cheers,
John

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 15 Nov 2021 18:53:59 +0200

On Sun, Nov 14, 2021 at 08:27:25AM +0000, John Mattsson wrote:
> 
> I promised to send some information to the list regarding security
> considerations for long connections. I think the (D)TLS 1.3 is
> lacking considerations on this as well so I made an issue for
> RFC8446bis.
> 

I expect most TLS stacks to happily continue the connection after
external PSK (I think those do not even have standard expiry
times) or certificate expires. And what about resumption PSKs?
Those do have expiry times (IIRC, capped to 7 days).

And then, certificate lifetime is complicated by possible presence of
CRL or OCSP. Do those affect certificate lifetime? And some PKIs
that actually take revocation seriously have point-in-time OCSP
which effectively expires instantly.

The problem with reauthentication is that the authentication might
change. And any changes might require very careful coordination at
application layer to avoid serious security issues. This is the
reason why HTTP/2 absolutely bans TLS renegotiation and post-
handshake authentication.

Adding (EC)DHE rekey might at least be possible to do transparently,
but TLS does not currently have such facility, so it would have to
be a new extension. And, actually doing this is very much nontrivial
cryptographically.

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 16 Nov 2021 13:37:01 -0500

On Sun, Nov 14, 2021 at 08:27:25AM +0000, John Mattsson wrote:

> considerations for long connections. I think the (D)TLS 1.3 is lacking
> considerations on this as well so I made an issue for RFC8446bis.
> 

The expiration of client certificates that were valid at the time of
connection estabishment does not look like a transport layer problem.

It rather appears to be an authorisation problem for the application
layer to deal with, if the connecting agent is no longer authorised
to perform some actions, that entitlement can be reverified when
serving the request.

On the server side, under what circustances do we imagine a service
provider to continue to maintain live connections (processes left
running, ...) on some endpoint system which are no longer legitimate
endpoints for the application?

The only thing that comes to mind is hostile takeover where the
legitimate operator loses operational control of the system, which
continues running.  I am sceptical that certificate expiration is a
sufficiently useful mechanism to militate this outcome, it is not likely
to be either timely or relevant.

The problem is the long connection lifetime, regardless of the lifetime
of the certificate, and if/when loss of operational control is a concern,
one should not keep connections running unreasonably long...

So yes, long connections can be an issue, but I rather think that
certificate lifetimes have little useful content in signalling or
addressing the problem.

-- 
    Viktor.

---

From: John Mattsson <[email-masked]>
Date: Sat, 20 Nov 2021 10:57:01 +0000

HI Ilari,

See inline.

Cheers,
John

From: Uta <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Date: Monday, 15 November 2021 at 17:54
To: [email-masked] <[email-masked]>
Subject: Re: [Uta] Long connections, forward secrecy, and key exfiltration, certificate lifetimes, exporter_secret
On Sun, Nov 14, 2021 at 08:27:25AM +0000, John Mattsson wrote:
> https://protect2.fireeye.com/v1/url?k=610edff0-3e95e6f2-610e9f6b-869a14f4b08c-219a0125a783924f&q=1&e=b021c5fe-71f9-4be3-b373-c1a2d2078447&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Ftls13-spec%2Fissues%2F1245

I expect most TLS stacks to happily continue the connection after
external PSK (I think those do not even have standard expiry
times) or certificate expires.

John: Yes, and I think they should. The application has the responsibility of External PSKs. I think TLS should just provide an alert (and an API) so that the application can signal to the other endpoint why it closed the connection. Reusing certificate_expiry seems like a good idea for external PSK.

And what about resumption PSKs?
Those do have expiry times (IIRC, capped to 7 days).

John: I would personally expect the TLS stack to close the connection. Continuing the connection after the ticket expired seems wrong. But preferably TLS should issue a new ticket and set up a new connection before that. An alert for this is missing. Might make sense to have a separate alert for this as a connection could be closed because the ticket expired, or the external PSK/certificate expired.

John: I think this would be the responsibility of the application. TLS should just provide transport of certificates, proof-of-possession, and OCSP stapling. When to send the information and what to do with the information is up to the application.

John: I think this is the applications responsibility. TLS should just provide ways to transfer the needed information when the application wants to do so.

John: Yes, right now setting up a new connection is the only choice. I don't know if that is the general solution of if a new extension should be added. For any non-constrained use cases I think (EC)DHE every hour or 100 GB as ANSSI recommends for IPsec makes a lot of sense. Unauthenticated (EC)DHE would protect against passive attackers, while authenticated with the long-term authentication or resumption PSK protect against some active attackers.

-Ilari

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 20 Nov 2021 23:16:55 -0500

On Sat, Nov 20, 2021 at 10:57:01AM +0000, John Mattsson wrote:

> John: Yes, and I think they should. The application has the
> responsibility of External PSKs. I think TLS should just provide an
> alert (and an API) so that the application can signal to the other
> endpoint why it closed the connection. Reusing certificate_expiry
> seems like a good idea for external PSK.

Ticket lifetimes are short so that servers can cycle through keys more
often, improving forward secrecy.  They can legitimately certainly have
much shorter lifetimetimes than the sessions established by using the
tickets.  There is no realistic threat model in which keeping a session
alive past ticket expiration has particular security relevance.

The only thing that matters is what reasonable lifetime to impose
sessions, which has no connection with either certificate or ticket
lifetimes.

-- 
    Viktor.