PALISADE v1.2 State Machine Diagrams

State descriptions (client)

• C_IDLE – No connection attempted.
• C_INITIATING – Local API has requested a new PALISADE session.
• C_WAIT_SH – ClientHello sent, waiting for ServerHello.
• C_VERIFY_SH – Validating ServerHello, certificate, and signature.
• C_DERIVE_KEYS – Deriving handshake and application keys.
• C_ESTABLISHED – Primary steady state: data can be sent and received.
• C_REKEY_PENDING – Client has requested an epoch change (rekey).
• C_RESUME_PENDING – Client is trying to resume with a ticket (0-RTT optional).
• C_CLOSING – Close has been initiated but not fully acknowledged.
• C_ABORT – Protocol violation or fatal error occurred.
• C_CLOSED – Terminal state; no further packets processed.

State descriptions (server)

• S_IDLE – Server not yet listening.
• S_LISTEN – Socket bound, waiting for ClientHello.
• S_WAIT_CH – Initial ClientHello received, parsing.
• S_VERIFY_CH – Optional client identity checks, feature negotiation.
• S_PREPARE_SH – ServerHello, key shares, and certificate being prepared.
• S_WAIT_FIN – Waiting for client's handshake completion.
• S_DERIVE_KEYS – Deriving post-handshake application keys.
• S_ESTABLISHED – Main steady state for a live tunnel.
• S_REKEY_PENDING – Processing a rekey (epoch change) request.
• S_RESUME_WAIT_CHR – Processing resumption attempts.
• S_CLOSING – Close initiated; connection draining.
• S_ABORT – Fatal protocol error or policy violation.
• S_CLOSED – Terminal state.

State Descriptions

• STEADY:
  • Only current_epoch keys exist
  • Accept only key_phase=0
  • Reject key_phase=1 (or accept but expect decrypt failure)
• TRANSITION (bounded duration):
  • Both current and next epoch keys exist
  • Accept key_phase=0 (current epoch) or key_phase=1 (next epoch)
  • Duration bounded by time T or packet count N (implementation-defined)
  • MUST NOT remain in TRANSITION indefinitely

Transitions

• STEADY → TRANSITION: Upon authenticated CTRL_REKEY receipt
  • Receiver calls ArmNextEpoch()
  • Sender calls InstallEpoch() and sets inTransition=true
• TRANSITION → STEADY: When commit criteria met
  • Time elapsed (maxTransitionTime exceeded)
  • Packet threshold reached (sufficient packets on new epoch)
  • Explicit control frame (if supported)
  • Receiver calls CommitEpochTransition()
  • Sender calls CompleteTransition()

Key Phase Behavior

• In STEADY state: Sender always sets key_phase=0
• In TRANSITION state: Sender sets key_phase=1 for packets on the new epoch
• Receiver in STEADY: Attempts decryption only with key_phase=0 (current epoch)
• Receiver in TRANSITION: Attempts decryption with indicated key_phase first, then alternate if first fails (max 2 attempts per packet)

Notes

• local_rekey_trigger may be:
  • key age limit exceeded,
  • byte counter threshold,
  • admin policy, etc.
• New epoch keys are derived from the key schedule and installed atomically with epoch state.
• The state machine ensures that key_phase=1 is only valid during authenticated transitions, preventing desync attacks.
• See PALISADE Specification Section 11.11 for normative requirements.

Notes

• The server MUST enforce max_early_data_bytes from the ticket, not from the client's offer.
• Rejected resumption should seamlessly fall back to a full ClientHello / ServerHello flow.
• Early data MUST be treated as replayable and safe only for idempotent operations.

Notes

• Migration is explicitly best-effort and not a full mobility solution.
• Validation may include round-trip validation, token proofs, or policy checks.
• Implementations MAY choose to disable migration entirely under PALISADE-CORE.

Notes

• A soft close should allow in-flight packets to drain where possible.
• A hard error is for unrecoverable conditions (integrity failure, version mismatch, etc.).
• Implementations SHOULD log close reasons for diagnostics, but MUST avoid leaking sensitive context.