16. Extensibility and Versioning

PALISADE is designed to be extensible while preserving strong interoperability and security guarantees.

Future protocol versions and extensions MUST adhere to the following principles:

Explicit Versioning

All protocol versions MUST be explicitly signaled during the handshake and MUST be bound into the handshake transcript prior to key derivation.

No Silent Downgrade

Implementations MUST NOT silently fall back to older protocol versions, weaker algorithms, or reduced security parameters without explicit negotiation.

Profile Stability

The PALISADE-CORE profile defines a stable baseline and MUST remain interoperable across future protocol versions unless explicitly deprecated.

Extension Isolation

Optional features and extensions MUST be cryptographically bound to the handshake transcript and MUST NOT alter PALISADE-CORE semantics unless explicitly negotiated.

Fail-Safe Defaults

Unknown protocol versions, extensions, or parameters MUST result in handshake failure rather than silent acceptance.

These constraints ensure that PALISADE can evolve to incorporate new post-quantum algorithms and features without introducing downgrade vulnerabilities or interoperability hazards.

16.1 Handshake Extensions

PALISADE supports optional handshake extensions using the following format:

HandshakeExtension =
    extension_type   (2 bytes, uint16)
    extension_length (2 bytes, uint16)
    extension_data   (extension_length bytes)

Normative requirements:

• Extensions MUST be encoded deterministically and included in the handshake transcript.
• Extensions MUST be processed only if explicitly recognized and supported.
• Unknown extensions MUST cause handshake failure unless the extension is explicitly specified as ignorable by the protocol definition.
• Extensions MUST NOT modify core protocol behavior unless explicitly negotiated.

16.2 Timestamp Field (OPTIONAL)

Status: OPTIONAL feature, disabled by default.

Rationale: Timestamps introduce clock-synchronization dependencies and operational complexity. PALISADE's primary replay protection mechanism is the epoch/sequence anti-replay window (see Section 8 and Appendix D). The timestamp field is provided solely as an optional defense-in-depth mechanism for deployments that require limited long-term replay detection.

Default Behavior (timestamps disabled)

• Implementations MUST set timestamp = 0.
• Implementations MUST NOT validate timestamps.
• Receivers MUST accept packets with timestamp = 0 without validation.

Enabled Behavior (optional)

When enabled, the timestamp field MAY be used for:

• Coarse diagnostic ordering information.
• Detection of very stale packets beyond the anti-replay window.

Encoding:

• The timestamp is a 32-bit unsigned integer.
• The RECOMMENDED encoding is seconds since session establishment.
• Implementations MAY alternatively use truncated UNIX time, provided both peers interpret the encoding consistently.

Validation Rules (when enabled)

Receivers MAY validate packet timestamps using:

current_time = now()
packet_time  = session_start_time + timestamp
drift        = abs(current_time - packet_time)

Packets MAY be discarded if:

• drift > Δ, where Δ defaults to 180 seconds.

Normative constraints:

• Implementations MAY configure Δ up to a maximum of 600 seconds.
• Implementations MUST NOT rely solely on timestamps for replay protection.
• Implementations MUST NOT reject packets solely due to timestamp failure if epoch/sequence validation succeeds.

Security Note:

Timestamp validation is defense-in-depth only. The epoch/sequence anti-replay window remains the authoritative replay protection mechanism. See Appendix D for replay protection semantics independent of timestamps.