feat(C10): add MCP protocol version downgrade prevention control (10.3.6)

[RicoKomenda]

Summary

Adds 10.3.6 to C10.3 (Secure Transport & Network Boundary Protection) to close the client-side gap left by 10.3.5, which only protects the version header from intermediary stripping.

New control:

Verify that MCP clients enforce a minimum acceptable protocol version and reject server capability negotiation responses that propose a version below that minimum, preventing a server or intermediary from forcing use of a protocol version with weaker security properties.

Level: 2

Why this is needed

The MCP specification uses an initialize handshake where the client proposes a version and the server responds with the version it will use. A malicious server or MITM intermediary could respond with an older version that lacks security features introduced in later revisions (e.g., improved message signing requirements, stricter origin validation). Without a client-enforced minimum version, the client silently downgrades.

10.3.5 already requires intermediaries not to strip the Mcp-Protocol-Version header. That protects against passive header stripping on streamable-HTTP. 10.3.6 adds the complementary client-side control: the client must actively enforce a minimum floor and abort the handshake if the server negotiates below it. Together these controls close both the passive (stripping) and active (malicious server response) downgrade paths.

This is directly analogous to TLS minimum version enforcement (which is standard practice and covered by 10.3.2) applied to the MCP application-layer protocol version.

Changes

• 1.0/en/0x10-C10-MCP-Security.md: add 10.3.6
• 1.0/en/0x93-Appendix-D_AI_Security_Controls_Inventory.md: add entry to AD.4