There are already a couple of things in TLS 1.3 that can be used to address some of these issues
From: Emu [mailto:emu-boun...@ietf.org] On Behalf Of Bernard Aboba Sent: Friday, January 19, 2018 9:46 AM To: emu@ietf.org Subject: Re: [Emu] EAP-TLS with large certificates Alan DeKok said: " It may also be worth re-examining EAP-TLS. Modern certificates are getting large, and people are using longer certificate chains. The result can be that initial EAP-TLS authentication takes many packets. This has issues not just for latency, but also access point implementations. Most implementations will drop an EAP session if it hasn't finished after 40-50 packets. I've seen people run into this issue with large certificates and long certificate chains. It would be good to find a way to allow this use-case." [BA] I have encountered this problem in a number of situations, particularly in enterprise deployments with several levels of intermediate CAs. Since the certificate hierarchy is relatively static, this seems like a problem that could be addressed via caching. [JLS] There is already a way to say that you have a specific set of certificates and CRLs in RFC 7924 – TLS Cached Information Extension. There is also a new TLS 1.3 extension that is being looked at for compressions of certificates. This seems to get some decent compressions, but it is still up in the air just how good it is going to be. For example, if client A has previously authenticated to server B and has cached the certificate chain, why does it need to be transmitted again? Similarly, if server B has already cached certificates from intermediate CAs, why does the client need to transmit that information again? Seems like this could be addressed by a small extension to TLS.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
