Slow connection clean up after ed25519 handshake failure

[tegefaulkes]

Specification

There is an odd delay when cleaning up the QUICConnection after a tls handshake error. After the client checks the server's certs and fails it, it sends the CC frame to close the connection. for a RSA cert the server enters draining and then the close state very quickly. But for a ed25519 cert the server processes the CC frame, waits an odd 3-ish seconds using the timeout(), onTimeout() timing mechanism and then enters the close state.

I don't see a reason why this would behave differently for an ed25519 cert compared to an RSA one. I've been over the internal logic and I think I'm handling all the events when and as intended. This 3 second delay is clearly being set after processing the CC frame with recv() on the server side AND doing processing a send(). This is also after both sides have entered the draining state, so no new packets are going to be sent between them.

Unless this is intended behaviour for handshakes with ed25519 certs, I can only assume this is some kind of bug. I've posed an upstream issue for this at cloudflare/quiche#1488.

Additional context

• Related Handshake failure waits 3 seconds before connection closes. cloudflare/quiche#1488
• Related Graceful connection failure for failed TLS handshake #9

Tasks

1. Determine the cause of this delay.
2. Fix the problem.

[CMCDragonkai]

It's also for ECDSA keypair.

[CMCDragonkai]

This is understood why now. It does happen under specific circumstances. Not a bug on our side. Fixed by #26.