Subject: Re: [Emu] EAP-TLS with large certificates

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Jan 2018 09:45:30 -0800

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.

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.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 19 Jan 2018 10:55:04 -0800

There are already a couple of things in TLS 1.3 that can be used to address some of these issues

From: Emu [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Friday, January 19, 2018 9:46 AM
To: [email-masked]
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?