alktls/docs/architecture/decisions/008-server-path-possession-verification.md

status, last_updated

status	last_updated
accepted	2026-09-11

ADR-008: Server-path proof-of-possession — the verifying verifier is the default

Status

Accepted (2026-09-11). Resolves OQ-TLS-09.

Context

Review 001 §S-1 (executed): AcceptAnyCertVerifier — then the default client-cert verifier on every TlsServerConfig path — never checked the client's CertificateVerify signature. Any party that observes a peer's public cert bytes (X.509) or SPKI (RFC 7250) could complete a handshake as that peer: the handshake completed, peer_certificates() yielded the victim's cert, and the extracted fingerprint — the identity every downstream auth decision consumes — was the victim's. The auth layer could not detect the spoofing: the fingerprint it was handed was the victim's.

The public cert/SPKI bytes are public by design — a peer must publish its identity to be dialable (branch-2 endpoints publish the same Ed25519 public key an SSH server would). So the observed-by-anyone attack surface was every peer identity in the stack, and the only proposed mitigation (challenge-response owned by the auth layer, the rewrite's option (a)) did not exist anywhere in the alk* codebase. The spoil was fully known and the fix fully specified — mirroring the signature routing the client-side FingerprintPinVerifier already implements — so "wait for a consumer" (the OQ's deferral framing) repeated the circular reasoning OQ-TLS-10 fell into: the component that must enable the consumer was deferring to the consumer it enables. The consumer designs are known (TCP/QUIC servers with X.509 or raw-key identities and identity-bearing clients — alkhttp, webtransport, the rewrite's endpoints); possession verification is needed by every one of them that authenticates by fingerprint.

Decision

VerifyPresentedCertVerifier is the default client-cert verifier on every TlsServerConfig path — X509, RawKey, SelfSigned, and ACME alike (the verifier install is crate-side rustls in new_acme, not rustls-acme's, so the ACME path flips identically). Its posture: request, don't require, verify possession.

• offer_client_auth() == true, client_auth_mandatory() == false, root_hint_subjects() == &[] — identical request-not-require shape to AcceptAnyCertVerifier (no-cert clients unaffected).
• verify_client_cert accepts any presented bytes — possession is proven by the CertificateVerify, not the cert's provenance; self-signed X.509 chains and bare RFC 7250 SPKIs remain valid presentation.
• verify_tls13_signature / verify_tls12_signature route by presented cert kind: an Ed25519 SPKI goes through verify_tls13_signature_with_raw_key (both TLS versions), an X.509 chain through the standard verify_tls{12,13}_signature — the same routing the client-side FingerprintPinVerifier implements, and the same functions rustls' webpki verifiers use.
• supported_verify_schemes() returns the nine-scheme list verbatim (shared with AcceptAnyCertVerifier; the exact-list pin covers both).
• requires_raw_public_keys() stays false — both cert types negotiate (ADR-007).

AcceptAnyCertVerifier stays public as the explicit no-pop escape hatch for a deployment that deliberately wants the old posture (handshake-speed over strictness, an auth layer that owns challenge-response). It is no longer installed by any crate path.

Mechanism note (rustls 0.23.44, server/tls13.rs): when a client presents a cert, rustls calls verify_client_cert then verify_tls13_signature(construct_client_verify_message(..), cert[0], sig) — the signature covers the transcript hash bound to the "TLS 1.3, client CertificateVerify" constant, so the check is a real proof-of-possession of the presented public key, not a replayable blob. A client presenting no cert skips both (the !mandatory branch). The attacker's failure mode is a signature under the attacker's key against the victim's public key: BadSignature (raw-key) or UnsupportedSignatureAlgorithmForPublicKeyContext (X.509 kind mismatch) — pinned by tests/impersonation_posture.rs.

What this buys — and what it deliberately does not

Bought: the extracted fingerprint is now authenticated as "the connecting party holds the private key for the presented public identity." The impersonation attack (victim's public bytes + attacker signer) fails the handshake on every default path, both cert types. This is the S-1 resolution for branches 1 and 2 (X.509 and raw-key TCP/QUIC endpoints with identity-bearing clients).

Not bought (deliberately, unchanged): no CA verification and no name verification — a self-signed chain remains valid presentation, and who a fingerprint maps to (the peer table, scopes, tokens) remains the auth layer's concern (ADR-005). The verifier proves possession; the auth layer still decides trust. This is exactly the split the crate's scope boundary prescribes (ADR-002).

Behavior-preservation invariants under the change

• The nine-scheme list, request-not-require shape, non-empty root store, 0-RTT, provider, and ALPN handling are untouched.
• Fail-closed: unchanged — and the new default adds a rejection where there was silent acceptance (the spoof), the direction that never breaks a legitimate composition.
• Legit compositions verified end-to-end (duplex handshakes, tests/handshake_behavior.rs): raw-key client pin ↔ raw-key server (suite 4), X.509 client ↔ X.509 server (suite 4b), raw-key client ↔ X.509 server (suite 3b) — all extract the client fingerprint under the verifying default. No-cert clients (browsers) unaffected. (Mapping note: the suite-number labels are the test-file's /// Suite N doc headers — the canonical handles are the test fns: suite 4 = raw_key_client_vs_raw_key_server_default_verifier_ checks_possession, 4b = x509_client_vs_default_verifier_ possession_checked, 3b = raw_key_client_presents_spki_and_ server_extracts_fingerprint.)
• QUIC parity: the CertificateVerify mechanism is handshake-level, identical under for_noq().

Consequences

Positive:

• S-1 closed out of the box: no deployment can accidentally run the spoofable posture; the escape hatch must be explicitly installed and its posture is test-pinned.
• The auth layer's fingerprint resolution can now treat the fingerprint as a possession-authenticated claim — the option-(c) challenge-response design becomes optional defense-in-depth rather than a prerequisite.
• Zero-consumer moment used correctly: flipping the default after first consumers would be a guaranteed breaking republish.

Negative:

• A legitimate client whose signer does not match its presented cert (a misconfigured CertifiedKey) now fails the handshake where it previously succeeded silently — the failure is the correct diagnosis (there is no such legitimate composition).
• One more public type on the API surface (additive; the freeze allows additions).

References

• OQ-TLS-09 (docs/architecture/open-questions.md) — resolved by this ADR
• tests/impersonation_posture.rs — both postures pinned (default rejects, escape hatch accepts), both cert types
• tests/handshake_behavior.rs — legit-composition pins (suites 1, 3b, 4, 4b)
• review 001 §S-1 — the discovery probe
• ADR-007 (cert-type negotiation), ADR-002 (scope boundary), ADR-005 (auth layer owns peer resolution)
• alknet ADR-034 — the request-but-don't-require shape this ADR refines (deviation recorded per AGENTS.md convention 10)
• rustls 0.23.44 server/tls13.rs (the CertificateVerify flow), webpki/verify.rs (verify_tls13_signature_with_raw_key)