Reject empty required client certificates

[algesten]

Summary

• Enforce require_client_certificate(true) when a client sends an empty Certificate message in DTLS 1.2 or 1.3.
• End the rejected handshake and send a fatal handshake_failure (DTLS 1.2) or certificate_required (DTLS 1.3) alert.
• Cover both wire paths with packet-driven regressions and confirm optional client authentication still completes.

[algesten]

Review cycle round 1: clean review. I traced both server handshake state machines and the certificate-required configuration, including the optional-client-auth paths. Both packet-driven empty-certificate regressions pass (cargo test --test dtls12 dtls12_empty_client_certificate_is_rejected_when_required --features rcgen and the corresponding dtls13 test). I found no actionable gap in the standalone dimpl behavior or test coverage.

[algesten]

Review cycle round 2: clean review of the full PR at a958b4f. The DTLS 1.3 alert uses epoch 3 after server Finished, when application keys are installed; the packet-driven test confirms the client decrypts certificate_required. Both server paths abort pending flights, close, and emit the specified fatal alert on a parsed empty Certificate. The four focused required/optional certificate tests pass. I found no actionable gap.

[algesten]

Related downstream PR: algesten/str0m#1067

This landed fix addresses the empty-client-certificate vulnerability described in str0m PR 1067. All five dimpl-based str0m backends retain the default require_client_certificate(true), so rejecting empty certificates in DTLS 1.2 and 1.3 prevents the reported handshake from completing without a PeerCert event and bypassing SDP fingerprint verification.

Verified locally at the landed commit eff1bf8: all six client-certificate tests across the DTLS 1.2 and 1.3 integration suites passed, including both empty-certificate rejection regressions and the optional-client-authentication tests.

str0m currently depends on dimpl 0.7.4. The 0.7.5 tag predates this fix, so str0m needs a release containing PR 170 before a version bump resolves the reported vulnerability. PR 1067 remains useful defense in depth against a backend emitting connection/keying-material events without a peer certificate.