release: 0.2.0-alpha.3 — round-3 reviewer feedback

Material change: verify_fingerprint_either_epoch now derives
fingerprints against BOTH current AND previous session keys
unconditionally during the rekey grace window, combining the
constant-time compares with bitwise `|` on bool (not
short-circuiting ||). Closes a timing distinguisher the reviewer
flagged: the alpha.2 "try current, fall back on mismatch" logic
leaked which key-epoch signed the consent via verify-path latency
(one HKDF on match, two on mismatch). The extra HKDF call is only
paid during the grace window.

SPEC §12.3.1 rekey interaction now requires this behavior
normatively. Same subsection gains a "design-evolution" note
surfacing the shift from an earlier "bind to initial key" plan to
the shipped "bind to current key, both-key probe on verify" —
rationale: no wire-level representation of "initial"; preserving
it fights Zeroize; grace window bounds probe cost the same way it
bounds AEAD-verify.

Documentation tightening:

- §12.6 LegacyBypass bluntly flagged as intentional compatibility
  mode. A LegacyBypass session silently discards valid consent
  ceremonies by design; security-sensitive deployments MUST NOT
  use it. Deployments landing on it by accident are strictly less
  secure than deployments that opt into ceremony mode.
- Appendix A vectors 07/08 relabeled draft-03 (stale "draft-02"
  caption — they were regenerated at draft-03 canonical bytes
  in 0.2.0-alpha.1 already).
- plans/REVIEW_DELTA_DRAFT_03.md updated per reviewer feedback:
    - "No other wire changes" reassurance near the top.
    - 2.2 BE-request_id defense rewritten from "mixed-convention
      mistake-reduction" to "domain-separated deterministic
      encoding, not a semantic property of big-endian."
    - 2.3 marked RESOLVED in alpha.3; narrowed to a reviewer-
      confirmation question.
    - 2.6 narrowed from open-ended coherence check to specific
      "are there missing timing-channel sinks?" question.
    - One-line rekey-design-evolution callout in §1.

No wire-format change. No API break. Peers on alpha.2 and
alpha.3 interoperate at the wire level.

106 tests green. Clippy clean (--all-features and
--no-default-features). `cargo package` unchanged in structure.

Author: Tristan-Stoltz-ERC

CHANGELOG.md

@@ -7,6 +7,70 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.2.0-alpha.3] — 2026-04-18
+
+Tracks **SPEC draft-03**. Round-3-reviewer-prompted hardening
+pass. No wire-format change, no API break. Receivers on
+0.2.0-alpha.2 and 0.2.0-alpha.3 interoperate at the wire level.
+
+### Security / Correctness
+
+- **Constant-time `verify_fingerprint_either_epoch`** (SPEC
+  §12.3.1 rekey interaction, now normative). The alpha.2
+  implementation derived the fingerprint against the current
+  session key, compared, and — on mismatch — derived against the
+  previous session key. One HKDF call on match, two on mismatch
+  — a timing distinguisher observable by an on-path attacker
+  that leaks which key-epoch the sender signed under. alpha.3
+  removes the distinguisher: when `prev_session_key` is present,
+  the verifier derives fingerprints against BOTH keys
+  unconditionally and ORs the constant-time compares with
+  bitwise `|` (not short-circuiting `||`). The extra HKDF call
+  is only paid during the rekey grace window.
+
+  The existing `verify_probes_prev_key_during_rekey_grace`
+  integration test covers functional correctness; the
+  constant-time property is a code-review assertion documented
+  in the updated `src/session.rs::verify_fingerprint_either_epoch`
+  and SPEC §12.3.1.
+
+### Documentation
+
+- **SPEC §12.3.1 rekey interaction**: now MANDATES the constant-
+  time both-key derivation. Adds a "design-evolution" note
+  surfacing the shift from an earlier "bind to initial key"
+  design to the shipped "bind to current key, both-key probe on
+  verify" design. Rationale captured: no wire-level
+  representation of "initial key"; preserving an initial key
+  fights zeroize; grace window bounds the probe cost
+  symmetrically with AEAD-verify.
+- **SPEC §12.6 `LegacyBypass`** — now documented bluntly as
+  intentional compatibility mode. A LegacyBypass session silently
+  discards valid, cryptographically authenticated consent
+  ceremonies **by design**. Security-sensitive deployments MUST
+  NOT use `LegacyBypass`; deployments that land on it by
+  accident are strictly less secure than deployments that opt
+  into ceremony mode.
+- **SPEC Appendix A** test-vector labeling: 07/08 now correctly
+  labeled as draft-03 (they were regenerated at the draft-03
+  canonical bytes in `0.2.0-alpha.1`; the "draft-02" caption
+  was stale).
+- **`plans/REVIEW_DELTA_DRAFT_03.md`** updated for round-3
+  reviewer: prominent "no other wire changes" reassurance near
+  the top; 2.2 BE-request_id defense rewritten as "domain-
+  separated deterministic encoding, not semantic meaning"; 2.3
+  timing side-channel marked RESOLVED (pointing at this
+  release) and narrowed to a reviewer-confirmation question;
+  2.6 narrowed from open-ended coherence check to a specific
+  "are there missing timing-channel sinks?" question. Adds a
+  one-line rekey-design-evolution callout.
+
+### Not changed
+
+- Wire format (envelope + signed canonical bodies) unchanged.
+- No API break.
+- No new dependencies.
+
 ## [0.2.0-alpha.2] — 2026-04-18
 
 Tracks **SPEC draft-03**. No wire-format change from 0.2.0-alpha.1;

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "xenia-wire"
-version = "0.2.0-alpha.2"
+version = "0.2.0-alpha.3"
 edition = "2021"
 rust-version = "1.85"
 authors = ["Tristan Stoltz <tristan.stoltz@evolvingresonantcocreationism.com>"]

SPEC.md

@@ -886,10 +886,37 @@ The reference implementation ships such a loop in
 session key. On rekey the fingerprint for the same `request_id`
 changes. Consent messages signed under the old key remain
 verifiable ONLY during the previous-key grace window (§6.2), and
-ONLY against the receiver's prev-key-derived fingerprint. A
-receiver implementing fingerprint verification MUST therefore
-re-derive against both the current and previous keys when the
-AEAD tag verified under the previous key, or reject the message.
+ONLY against the receiver's prev-key-derived fingerprint.
+
+A receiver implementing fingerprint verification during the rekey
+grace window MUST derive fingerprints against **both** the current
+and the previous session keys unconditionally, and MUST combine
+the constant-time compares with a non-short-circuiting bitwise OR.
+Naïve "derive against current; if no match, derive against prev"
+logic creates a timing distinguisher observable by an on-path
+attacker: latency reveals which key-epoch the sender signed under,
+which is sensitive metadata about session state near rekey. The
+extra HKDF-SHA-256 call is cheap (microseconds on commodity
+hardware) and only paid during the grace window; outside grace
+there is only one key and only one derivation. The reference
+implementation's `Session::verify_fingerprint_either_epoch`
+realizes this requirement.
+
+> **Note on design evolution (draft-03).** An earlier draft of the
+> fingerprint design bound to the *initial* session key so the
+> fingerprint would be stable across rekeys. The shipped design
+> instead binds to the *current* key and handles rekey at the
+> verifier via both-key derivation. Rationale: (a) "initial key"
+> has no wire-level representation (a peer that joined mid-session
+> has no notion of "initial"), whereas "current + previous" is
+> already maintained by every receiver for AEAD verification;
+> (b) binding to the initial key would require callers to
+> preserve a key they are otherwise encouraged to zeroize;
+> (c) the rekey grace window is bounded (§6.2 default 5s), so the
+> cost of the verifier's both-key probe is bounded in exactly the
+> same way. This is a real change from the initial design
+> rationale; it is documented here so reviewers can distinguish
+> evolution from inconsistency.
 
 **Why MANDATORY, not OPTIONAL.** draft-02r1 documented loose
 binding as a known limitation. draft-03 closes it by making the
@@ -1015,6 +1042,20 @@ Every session SHALL track consent state, one of six variants. Two
   auto-promote a LegacyBypass session into `Requested` — that
   would let a malicious peer force a NoConsent block on a session
   that opted out of the ceremony.
+
+  **This is intentional compatibility behavior, not an emergent
+  property of the state machine.** A LegacyBypass session
+  silently discards valid, cryptographically authenticated
+  consent ceremonies by design. Security-sensitive deployments
+  MUST NOT use `LegacyBypass`; those deployments construct
+  sessions via `SessionBuilder::require_consent(true)` so they
+  start in `AwaitingRequest`. `LegacyBypass` exists to preserve
+  draft-02 "consent handled out-of-band" behavior for
+  backward-compatibility with deployments whose authorization
+  lives entirely above the wire (MSP pre-authorization,
+  deployment-level trust anchors, etc.). Deployments that land
+  on `LegacyBypass` by accident are strictly less secure than
+  deployments that opt into ceremony mode.
 - **`AwaitingRequest`** — the consent system IS in use; no
   `ConsentRequest` has been observed yet. Application payloads are
   blocked until a ceremony completes (interpretation (2) of the
@@ -1267,8 +1308,8 @@ an alternate implementation can reproduce every byte:
 | 04 | `long_payload` | 256 bytes covering every byte value. |
 | 05 | `nonce_structure` | Three sequential seals, seq counter increments. |
 | 06 | `lz4_frame` | LZ4-before-AEAD pipeline. |
-| 07 | `consent_request` | draft-02 ConsentRequest signed with deterministic Ed25519 seed. |
-| 08 | `consent_response` | draft-02 ConsentResponse approving vector 07. |
+| 07 | `consent_request` | draft-03 ConsentRequest signed with deterministic Ed25519 seed; includes the mandatory `session_fingerprint`. |
+| 08 | `consent_response` | draft-03 ConsentResponse approving vector 07; distinct responder seed; shares the same `session_fingerprint` as 07. |
 | 09 | `consent_revocation` | draft-03 ConsentRevocation signed by vector 08's responder; shares the session_fingerprint of 07 + 08. |
 | 10 | `revocation_before_approval` | draft-03 event-sequence fixture: `ConsentViolation::RevocationBeforeApproval` from `AwaitingRequest` AND from `Requested`. |
 | 11 | `contradictory_response` | draft-03 event-sequence fixture: `ConsentViolation::ContradictoryResponse` in both directions (prior=true→new=false and prior=false→new=true). |

plans/REVIEW_DELTA_DRAFT_03.md

@@ -1,6 +1,6 @@
 # Round-3 review — delta since draft-02r1
 
-**Target version**: `xenia-wire 0.2.0-alpha.2` / SPEC **draft-03**.
+**Target version**: `xenia-wire 0.2.0-alpha.3` / SPEC **draft-03**.
 **Assumed prior context**: you last reviewed **draft-02r1**
 (`xenia-wire 0.1.0-alpha.3` / `alpha.4`, April 2026), which flagged
 four open design items: session-binding (loose), split-Pending,
@@ -19,6 +19,12 @@ Section-number references (e.g., §12.3.1) are to SPEC.md at
 `v0.2.0-alpha.2`. Source-file references are to the reference
 implementation at the same tag.
 
+**No other wire changes.** §1–§11 (envelope layout, nonce
+construction, replay window, AEAD, payload type registry) are
+byte-for-byte identical to draft-02r1. All deltas live in the
+signed-body layer (§12), and — within the signed-body layer —
+the receive-side state machine and fingerprint verification.
+
 ---
 
 ## 1. Deltas since draft-02r1
@@ -89,6 +95,17 @@ a hazard.
   AEAD-verified under the previous key during the grace window
   now also passes the fingerprint check. §12.3.1 rekey
   interaction spells this out.
+
+  > **Design-evolution note (surfacing an earlier divergence).**
+  > An earlier internal plan bound the fingerprint to the
+  > *initial* session key so it would be stable across rekeys.
+  > The shipped design binds to the *current* key and handles
+  > rekey via the verifier's both-key probe. Rationale is
+  > captured in §12.3.1 (no wire-level representation of
+  > "initial"; preserving an initial key fights zeroization;
+  > the grace window bounds the probe cost the same way it
+  > bounds AEAD-verify). Flagged here so it reads as evolution
+  > rather than inconsistency.
 - **Timing-channel assumption (§12.8)** — new paragraph. Asserts
   the verify pipeline (bincode deserialize, Ed25519 verify,
   fingerprint compare) MUST NOT branch on secret-dependent bytes.
@@ -134,35 +151,48 @@ replay threat model, or should `pld_type` be mixed into `info`?
 **The question.** SPEC §12.3.1 specifies `request_id_be` — the u64
 in big-endian. Every other integer on the Xenia wire is
 little-endian (per bincode v1 default; nonce sequence bytes are
-explicitly LE per §3). The mixed convention is intentional — we
-wanted the `info` byte-order to differ from the ambient wire so
-that an implementation reaching for a "byte-encode this u64 the
-usual way" path would produce the wrong fingerprint and fail
-loudly rather than silently.
-
-**Specific ask.** Is this mistake-reduction smart, or is it a
-footgun that buys nothing because the endianness is already
-specified normatively either way?
-
-### 2.3 Timing side-channel in `verify_fingerprint_either_epoch`
-
-**The question.** On the receive path, `verify_consent_*` derives
-the fingerprint against the **current** key, compares, and — only
-if that fails — derives again against the **previous** key.
-That's one HKDF call on match, two on mismatch. Relevant source:
-`src/session.rs::verify_fingerprint_either_epoch` (around line
-340-360 in the 0.2.0-alpha.2 tree).
-
-An attacker observing verify-path timing could distinguish
-"accepted under current key" from "accepted under prev key" from
-"rejected". The latency delta is ~one HKDF-SHA-256 derivation
-(~a few microseconds on commodity hardware). Is this exploitable?
-
-**Mitigation considered.** Always derive both fingerprints
-regardless of first-match outcome; compare each; OR the
-constant-time compare results. Constant-time verify path at the
-cost of one extra HKDF call per verify. Open to your opinion on
-whether this is worth the complexity.
+explicitly LE per §3).
+
+**Framing (rewritten for clarity).** The choice is intentionally
+domain-separated deterministic encoding — not a claim that
+big-endian is semantically meaningful for `request_id`. HKDF's
+`info` parameter needs fixed, unambiguous bytes; any normative
+byte order works. Picking BE here means a careless implementer
+who reuses the ambient LE encoding path produces an obviously
+wrong fingerprint and fails at the verify step, instead of
+silently producing a wrong-but-plausible output. The defensive
+effect is the whole reason; it's not a cryptographic property.
+
+**Specific ask.** Is this defensive asymmetry worth it, or
+does the interop cost of the mixed convention outweigh the
+mistake-reduction gain? We're open to normalizing to
+little-endian in a future breaking draft if the reviewer
+recommends it — but that's a future-draft decision, not a
+draft-03 one.
+
+### 2.3 Timing side-channel in `verify_fingerprint_either_epoch` (RESOLVED in 0.2.0-alpha.3)
+
+**Original question.** The 0.2.0-alpha.2 implementation of
+`verify_fingerprint_either_epoch` derived the fingerprint against
+the current key, compared, and — on mismatch — derived against
+the previous key. That's one HKDF call on match, two on
+mismatch, which leaks which key-epoch signed the consent via
+verify-path latency.
+
+**Resolution (0.2.0-alpha.3).** The reference implementation now
+derives fingerprints against BOTH keys unconditionally whenever
+`prev_session_key` is present, and combines the constant-time
+compares with a non-short-circuiting bitwise OR (`bool` `|`, not
+`||`). The extra HKDF-SHA-256 call is only incurred during the
+grace window. SPEC §12.3.1 rekey interaction now states this as
+a normative MUST for receivers.
+
+**Ask becomes:** review confirmation that the fix is sufficient.
+If an attacker can still distinguish "grace window active" from
+"no grace" via the absence of the second derivation, that's a
+known protocol-visible state (the presence of a prev key is not
+secret), so we don't think further masking is needed. Please
+confirm this reasoning.
 
 ### 2.4 Transition-table completeness (§12.6.1)
 
@@ -198,17 +228,21 @@ just *that* they did. Currently a replayed (same-value)
 `ConsentResponse` would be indistinguishable from the original in
 a frozen transcript.
 
-### 2.6 General coherence of §12.8 security properties + §12.10 out-of-scope
-
-**The question.** §12.8 now enumerates: third-party-verifiable
-signed consent, TIGHT session binding, protocol-violation
-detection, no human-identity binding, and the timing-channel
-assumption. §12.10 lists the explicit out-of-scope items (coerced
-consent, human-identity fraud, clock-skew attacks).
-
-Is there a property draft-03 implicitly offers that §12.8 should
-claim explicitly? Or a threat draft-03 implicitly tolerates that
-§12.10 should flag? Open-ended reality-check question.
+### 2.6 §12.8 timing-channel scope — any missing sinks?
+
+**The question.** §12.8 enumerates three operations on the verify
+path that MUST NOT branch on secret-dependent bytes: bincode
+deserialization of the signed body, Ed25519 signature verify, and
+the 32-byte constant-time fingerprint compare. Did we miss a
+fourth timing-observable? Two candidates we considered and
+rejected as not-a-sink: the Ed25519 `from_slice` signature-length
+check (the signature length is 64 bytes and public), and
+bincode's length-prefix parse for the `reason: String` field
+(the length byte is part of the attacker-controlled input
+rather than a secret).
+
+**Specific ask.** Confirm the three-sink list is exhaustive, or
+point at a sink we missed.
 
 ---
 

src/session.rs

@@ -305,32 +305,52 @@ impl Session {
         out
     }
 
-    /// Probe both the current and (if present) previous session
-    /// keys for a fingerprint match against `claimed` (SPEC
-    /// draft-03 §12.3.1 rekey interaction). Constant-time compare
-    /// on each candidate.
+    /// Probe the current and (if present) previous session keys for
+    /// a fingerprint match against `claimed` (SPEC draft-03 §12.3.1
+    /// rekey interaction).
     ///
-    /// Returns `true` iff either derivation matches. Returns
-    /// `false` if no key is installed.
+    /// When the previous session key is present (i.e. we are within
+    /// the rekey grace window), this function derives fingerprints
+    /// from BOTH keys unconditionally and combines the constant-
+    /// time compares with a non-short-circuiting bitwise OR (`|`
+    /// on `bool`, not `||`). This removes the timing distinguisher
+    /// that a naive "try current first, fall back to prev on
+    /// mismatch" implementation would leak — a remote observer of
+    /// verify-path latency otherwise learns which key-epoch the
+    /// counterparty signed the consent under, which is sensitive
+    /// metadata about session state near rekey.
+    ///
+    /// The extra HKDF-SHA-256 call is cheap (~microseconds on
+    /// commodity hardware) and only incurred while `prev_session_key`
+    /// is Some — i.e. during the grace window. Outside the grace
+    /// window there is only one key and only one derivation.
+    ///
+    /// Returns `true` iff either derivation matches. Returns `false`
+    /// if no key is installed.
     #[cfg(feature = "consent")]
     fn verify_fingerprint_either_epoch(
         &self,
         request_id: u64,
         claimed: &[u8; 32],
     ) -> bool {
-        if let Some(key) = self.session_key.as_ref() {
-            let fp = self.session_fingerprint_from_key(request_id, key);
-            if ct_eq_32(&fp, claimed) {
-                return true;
+        let current_match = match self.session_key.as_ref() {
+            Some(key) => {
+                let fp = self.session_fingerprint_from_key(request_id, key);
+                ct_eq_32(&fp, claimed)
             }
-        }
-        if let Some(prev) = self.prev_session_key.as_ref() {
-            let fp = self.session_fingerprint_from_key(request_id, prev);
-            if ct_eq_32(&fp, claimed) {
-                return true;
+            None => false,
+        };
+        let prev_match = match self.prev_session_key.as_ref() {
+            Some(prev) => {
+                let fp = self.session_fingerprint_from_key(request_id, prev);
+                ct_eq_32(&fp, claimed)
             }
-        }
-        false
+            None => false,
+        };
+        // Bitwise OR on `bool` — NOT short-circuiting `||`. The `|`
+        // variant forces both operands to be evaluated and combined
+        // without control-flow branches on the intermediate values.
+        current_match | prev_match
     }
 
     /// Sign a [`ConsentRequestCore`] after injecting the session