Surfaced during the v0.1.0 review (PR #2). Related to the Core-baseline conversation in PR #2.
The handshake exchanges profiles_supported and signature_algorithms_supported from the client and returns profiles_accepted from the server. Nothing on the wire commits subsequent traffic to that negotiated set.
The failure mode: a MITM that strips signatures from the ServerHello during handshake (returns empty signature_algorithms_supported and profiles_accepted minus acs-crypto) produces a downgraded session that both sides accept. After that, all traffic is forgeable. The same pattern lets an attacker downgrade a session intended to require acs-provenance into one that doesn't, silently.
Proposed direction (transcript binding):
- Option (a): the first signed request in the session commits to a hash of the (ClientHello, ServerHello) tuple via a
handshake_transcript_hash field, which subsequent signatures cover transitively
- Option (b): the handshake itself is signed under a long-lived identity key, separate from the per-session signature key
(a) is lighter weight and doesn't require a separate identity key infrastructure. (b) is stronger because it doesn't depend on at least one signed request following the handshake.
Why deferred from v0.1.0: this only matters if signing is mandatory in some form, which lives in the Core-baseline conversation on PR #2. Filing separately so we can track the transcript-binding design independent of the "what goes in Core" question.
References: specification.md §4, handshake.json, request-envelope.json Signature
Surfaced during the v0.1.0 review (PR #2). Related to the Core-baseline conversation in PR #2.
The handshake exchanges
profiles_supportedandsignature_algorithms_supportedfrom the client and returnsprofiles_acceptedfrom the server. Nothing on the wire commits subsequent traffic to that negotiated set.The failure mode: a MITM that strips signatures from the ServerHello during handshake (returns empty
signature_algorithms_supportedandprofiles_acceptedminusacs-crypto) produces a downgraded session that both sides accept. After that, all traffic is forgeable. The same pattern lets an attacker downgrade a session intended to requireacs-provenanceinto one that doesn't, silently.Proposed direction (transcript binding):
handshake_transcript_hashfield, which subsequent signatures cover transitively(a) is lighter weight and doesn't require a separate identity key infrastructure. (b) is stronger because it doesn't depend on at least one signed request following the handshake.
Why deferred from v0.1.0: this only matters if signing is mandatory in some form, which lives in the Core-baseline conversation on PR #2. Filing separately so we can track the transcript-binding design independent of the "what goes in Core" question.
References:
specification.md§4,handshake.json,request-envelope.jsonSignature