HI Ilari, See inline.
Cheers, John From: Uta <uta-boun...@ietf.org> on behalf of Ilari Liusvaara <ilariliusva...@welho.com> Date: Monday, 15 November 2021 at 17:54 To: uta@ietf.org <uta@ietf.org> 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: > > 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://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. 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. 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. 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. 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. 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. 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 Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
