Threat Model

1. Objectives of This Threat Model

The purpose of this appendix is to clearly articulate:

• Which adversaries PALISADE is designed to resist
• Which capabilities must be assumed for the adversary
• Which attacks PALISADE explicitly prevents
• Which attacks PALISADE does not attempt to address (scope boundaries)
• Which assumptions must hold for PALISADE's security claims

2. System Model

PALISADE is an authenticated key exchange (AKE) protocol that establishes an encrypted bi-directional tunnel between two endpoints:

• A client (initiator), and
• A server (responder).

Endpoints communicate over a potentially hostile network, with no assumptions of confidentiality, integrity, or authenticity at the transport layer.

The protocol uses:

• Post-quantum KEMs for forward-secure shared-secret derivation
• Post-quantum signatures for endpoint authentication
• AEAD for confidentiality, integrity, and replay protection
• Transcript-binding for channel-binding and downgrade protection

This threat model describes what classes of attackers PALISADE v1.1 aims to resist.

3. Adversarial Model

We consider an adversary A with the following capabilities unless otherwise restricted.

3.1 Network Adversary (Standard Dolev–Yao)

A may:

• Observe all traffic
• Drop, delay, reorder, or duplicate packets
• Inject arbitrary packets
• Modify packet contents
• Spoof source and destination addresses
• Attempt replay of captured packets
• Attempt to induce migration via path or routing manipulation
• Interfere with handshake, rekey, or resumption flows

This is the classic "full network attacker."

3.2 Cryptographic Adversary

A may attempt:

• Forgery of KEM ciphertexts
• Forgery of PQ signatures
• Breaking AEAD integrity or confidentiality
• Breaking transcript hashes
• Breaking the key schedule via input manipulation
• Offline dictionary or guessing attacks (if weak secrets were allowed)
• Downgrade attacks
• Replay attacks
• Reflection attacks
• Manipulation of optional fields
• Identity misbinding

PALISADE assumes the cryptographic primitives remain unbroken at NIST Category 3+ security.

3.3 Side-Channel Adversary (Limited Scope)

PALISADE assumes:

• Timing side channels at the cryptographic primitive level are implementation responsibilities.
• The protocol does not rely on hiding message sizes unless padding is explicitly configured.
• No protections against hardware-level side channels (e.g., power analysis) are attempted at the protocol layer.

3.4 Endpoint Compromise (Post-Compromise Security)

We consider:

• A compromised endpoint fully breaks the security of the session keys it holds.
• PALISADE does not provide post-compromise forward secrecy (PCFS) beyond standard rekeying.
• Rekey events limit exposure but do not restore secrecy if endpoints remain compromised.

4. PALISADE Security Goals

PALISADE is designed to achieve the following formal goals, expressed in common AKE literature terms.

4.1 Mutual Authentication

Both endpoints confirm:

• The identity of the peer
• The peer's possession of the private authentication key
• The peer's participation in the same handshake transcript

4.2 Confidentiality & Integrity of Application Data

Achieved via AEAD encryption under derived epoch keys.

4.3 Forward Secrecy (post-quantum)

Compromise of long-term private keys does not compromise:

• Past session keys
• Past application data

KEM ephemeral secrets and transcript-bound derivations enforce this.

4.4 Replay Protection

PALISADE ensures that:

• No handshake message can be replayed
• No application packet can be replayed unless the attacker can guess (epoch_id, seq) or forge AEAD

This is enforced through:

• Epoch counters
• Sequence numbers
• Transcript hashes
• AEAD integrity

4.5 Downgrade Protection

Downgrades involving:

• Version
• Selected KEM
• Selected signature scheme
• AEAD
• Optional features

Are prevented by transcript-binding and mandatory refusal on mismatched parameters.

4.6 Identity Misbinding Protection

ServerHello and certificate messages are bound to the handshake transcript to prevent:

• Unknown key-share attacks
• Substitution attacks
• MITM identity confusion

4.7 Resumption Security

Resumption tickets:

• Are bound to the original authenticated connection
• Contain explicit max_early_data_bytes
• Are single-use and privacy-preserving
• Prevent replay amplification

4.8 Migration Security

Migration is:

• Optional (PALISADE-PLUS only)
• Non-transparent (best-effort, not a mobility guarantee)
• Authenticated via binding tokens
• Resistant to malicious path spoofing
• Resistant to off-path adversaries

5. Out-of-Scope Attacks

The following are explicitly outside PALISADE's security model.

5.1 Endpoint compromise

If endpoints are compromised, PALISADE does not attempt:

• Key healing
• State recovery
• Post-compromise secrecy (beyond optional rekey)

5.2 Metadata Protection

While PALISADE encrypts header contents, it does not attempt to protect:

• Packet timing
• Packet sizes (beyond padding)
• Traffic patterns
• Flow characteristics

5.3 Side Channels

PALISADE does not address:

• Cache timing
• Branch prediction leakage
• Power analysis
• Electromagnetic leakage
• Microarchitectural attacks

5.4 Denial of Service (DoS)

PALISADE mitigates some DoS vectors (e.g., stateless rejects) but does not:

• Guarantee connection success under DoS
• Defend against bandwidth exhaustion
• Defend against CPU exhaustion attacks

5.5 Routing Security

The protocol does not attempt to solve:

• BGP hijacking
• DNS spoofing (outside of endpoint identity validation)
• WAN link manipulation

Though migration includes some validation, it is not a routing security protocol.

6. Threat Model Summary Table