From the article I can see that using ECDSA instead of RSA could save up to 400 bytes per connection - that's nice.
Aside from certificate and key size, my understanding is that ECDSA is less computationally intense than RSA, but this gets only a brief mentioned in the article - does anyone know how CPU use compares for typical setup of a TLS connection for ECDSA vs RSA?
Here's a 2017 Cloudflare blog post that compares the performance of ECDSA sign and verify operations (using 256 bit keys) against RSA sign and verify operations (using 2048 and 3072 bit keys) on various CPU architectures:
- Do the graphs mean that the "sign" operation of OpenSSL when using ECDSA is many times faster and the "verify" operation is ~4 times slower (compared to RSA)?
- I suppose that "sign" is linked to issuing certificates, while "verify" would be involved to checking certificates?
If it were just checking and issuing certificates, faster signing and slower verifying would be a bad tradeoff, since certificates are issued once and used many times; certificate size benefits notwithstanding.
The really nice thing performance wise is that when sending a certificate via TLS, you need to sign the TLS exchange up to that point. Making that faster means you can support a lot more connection handshakes with the same server.
It makes sense to use ECDSA for leaf certificates, because the TLS server can then handle more clients compared to a RSA based certificate of the same strength (the private key operation is much cheaper with ECDSA and is needed for every TLS handshake). The client of course, needs a few more cycles to verify the signature, but that is not noticeable most of the time.
IMHO it does not really make sense to use a ECDSA root certificate unless you have a very constrained environment, where every byte counts. The root certificate will never be transferred to the client during a TLS handshake - so the size benefit is minimal (the intermediate certificate will be a bit smaller, because ECDSA signatures are smaller). But the signature validation will take more cycles on the client in every TLS handshake.
Other than that it is a good thing that Let's Encrypt now has an ECDSA root. When researchers might find a problem with RSA in the future, we have an alternative ready to use.
Aside from certificate and key size, my understanding is that ECDSA is less computationally intense than RSA, but this gets only a brief mentioned in the article - does anyone know how CPU use compares for typical setup of a TLS connection for ECDSA vs RSA?