docs: record 11.5.6 spike — QUIC channel binding constraints

Investigated aioquic 1.3.0 before implementing the QUIC challenge/response,
since the binding anchor gates the whole design.

No RFC 5705 exporter exists (aioquic.tls.Context has no export_keying_material),
so the preferred anchor is unavailable. Certificate access is asymmetric: the
server reaches its own cert via the public tls.certificate, but the client can
only reach the server's via tls._peer_certificate — a private attribute, behind
a QuicConnection that exposes no tls accessor at all.

That matters because binding a security check to a private API means an
upgrade can remove it silently. Since make_proof() refuses an empty binding
(11.5.21), a rename would fail loudly rather than degrade — but only while the
refusal path stays strict.

Three options recorded with a recommendation: certificate hash via the private
attribute with a guard test that fails CI on upgrade, plus pinned aioquic;
or bind to pk_node instead, which for QUIC may suffice since signaling is not
hub-relayed — but that requires certificate pinning, as the QUIC client
currently does not verify the TLS certificate at all; or upstream an exporter.

No implementation started: the challenge/response needs both protocol sides,
test updates in two files and multiple verification cycles.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions