How and when the CertificateVerify is generated in TLS 1.3?

Question

I am comparing the performance of the ECDSAP256 signature algorithm and RSA3072 on OpenSSL.

I first used openssl speed to test algorithm performance:

• RSA3072 signs 356.2 time/second and verify 17625.1 time/second;

• ECDSAP256 signs 28096.7 time/second and verify 9462.5 time/second;

Then I created a server with a P256 certificate and a server with an RSA3072 certificate. Both of them are signed by a self-signed root CA. All these certificates are created using the OpenSSL command. They are stored in folder ecc_test and rsa_test respectively.

I tested the handshake performance using openssl s_server and openssl s_time on TLS 1.3. The result showed here:

• RSA3072:

7380 connections in 5.02s; 1470.12 connections/user sec, bytes read 0
7380 connections in 31 real seconds, 0 bytes read per connection

• P256

19755 connections in 16.49s; 1198.00 connections/user sec, bytes read 0
19755 connections in 31 real seconds, 0 bytes read per connection

The testing commands are here, $1 need to be replaced by the folder name ecc_test or rsa_test:

openssl s_server -key $1/server/server.key -cert $1/server/server.pem -accept 4330 
-CAfile $1/rootCA/demoCA/root.pem -verify_return_error -state -WWW

openssl s_time -connect localhost:4330 -CAfile $1/rootCA/demoCA/root.pem -new

I first thought the result is reasonable since RSA3072 verify faster than P256. But then I realize that in TLS 1.3 server needs to send a CertificateVerify which is signed using the server's private key. Therefore, in theory, the server using the P256 certificate should set up the handshake faster than the server using the RSA3072 certificate.

Then I run s_client with -msg and I found that the CertificateVerify was indeed generated and sent. Both servers use x25519 for key exchange.

Is there any error in my experiment?

How did the CertificateVerify generate? Could it be generated before the handshake?

Answer 1

By default, the openssl s_time command performs two types of connection in sequence. The first is a normal connection as if it were a brand new client, and the second is a resumption re-using the session ID from that previous connection. Session resumptions do not require a full handshake with a CertificateVerify, and they are much faster (particularly in TLS 1.3) than a regular connection. This explains why you're seeing more than twice as many connections per second for RSA than you are in the openssl speed test - half of the connections aren't doing any RSA signature operations at all.

This explains why your results are coming out skewed. You can fix this with the -new flag, which tells openssl s_time to only perform new connections and no session resumptions.

It's also worth keeping in mind that 660 signs per second means just 1.5 milliseconds are spent performing the RSA portion of the handshake. ECDSA is obviously faster (about 19 microseconds) but it won't make a huge difference in practical handshake time over the internet because each network round trip typically takes 10-30ms, and TLS 1.3 handshakes require two round trips (ignoring 0-RTT). The main benefit of moving to ECDSA is the lower compute cost (i.e. less CPU overhead and lower energy usage) rather than the comparatively small decrease in per-handshake time.