On Mar 12, 2018, at 10:40 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
I'm currently looking at https://www.ietf.org/id/draft-mattsson-eap-tls13-02.txt.
I'll be at the IETF next Monday, trying to convince them to Do the Right Thing.
It states that:
While Elliptic Curve Cryptography (ECC) was optional for earlier version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of [I-D.ietf-tls-tls13]). To avoid fragmentation, the use of ECC in certificates, signature algorithms, and groups are RECOMMENDED when using EAP-TLS with TLS 1.3 or higher.
That sounds like useful advice.
Yes.
I'm wondering though what to do if you have a diverse variety of client devices doing EAP; some of which only do TLS 1.2 while others do TLS 1.3.
"When in danger or in doubt, run in circles, scream and shout." :)
The EAP server can only present one certificate to its incoming peer connections.
It should be able to pick the "right" certificate.
If it has a ECDSA certificate, there's a chance for an interop problem with TLS 1.2 clients not supporting the needed cipher suites.
If it has a RSA certificate, it misses out on the small-cert benefits.
Yes.
I wonder if it's possible to have both certificates available to the server, with a late selection: depending on which TLS version has been negotiated, present one cert or the other.
Is that kind of stuff doable?
Ask OpenSSL. :( We can do almost anything on our end. Getting the OpenSSL magic correct may be a bit harder. The OpenSSL documentation is a weird combination of exhaustive, and completely unhelpful. If anyone can take a look at how Apache does it, that would help. Simply knowing which OpenSSL calls to do, and in what order, will solve 99% of the problem. Alan DeKok.