The MyClerk Protocol: Tiered Security Communication for Distributed Family Systems

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Terminology

Node

A device participating in a MyClerk deployment, such as a server, desktop client, mobile device, or IoT device.¶

Core Node

A node classified as stable and reliable, expected to maintain high availability (>95% uptime over 30 days).¶

Bonus Node

A node with variable availability, used opportunistically for additional redundancy.¶

Family

A group of users and nodes sharing a common trust domain and cryptographic key hierarchy.¶

Federation

The interconnection of multiple families for resource sharing or communication.¶

Tier

A security level (0-5) determining the header structure and cryptographic protections applied to a message.¶

Session

A stateful connection between two endpoints with established cryptographic keys.¶

2.1. Design Goals

1. Tiered Security: 1-144 bytes overhead depending on security requirements.¶
2. Transport Agnostic: Operates over NATS, Matrix, WebSocket, TCP, or other transports.¶
3. Federation Ready: Supports multi-server, multi-family deployments.¶
4. Future Proof: Extensible operations and feature negotiation.¶
5. Post-Quantum Security: Default key establishment for Tier 4 and Tier 5 is resistant to attacks by cryptographically relevant quantum computers (CRQCs), using a hybrid of ML-KEM-768 [FIPS203] and X25519 [RFC7748], while retaining a classical-only mode for resource-constrained devices.¶

2.2. Default Port

When using TCP or UDP as the transport protocol, implementations SHOULD use port 5657 as the default listening port. This port is registered with IANA for the "myclerk" service (see Section 11.1).¶

Implementations MAY use alternative ports when:¶

• Operating behind a reverse proxy or load balancer¶
• Running multiple instances on the same host¶
• Required by local network policies¶

Service discovery mechanisms (such as mDNS or DNS-SD) SHOULD advertise the actual port in use, regardless of whether it matches the default.¶

2.3. Security Tiers Overview

KEX abbreviations: "hybrid" denotes ML-KEM-768 + X25519 hybrid key establishment; "from T4/T5" indicates the session key is derived in a separate Tier 4 or Tier 5 handshake and inherited by subsequent Tier 3 traffic.¶

3.1. Common Header Fields

The first byte (Flags) is present in all tiers and has the following structure:¶

 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V V|T T T|C|S|E|
+-+-+-+-+-+-+-+-+

V: Protocol Version (2 bits) - 0 or 1
T: Security Tier (3 bits) - Values 0-5
C: Compressed (1 bit) - Payload is compressed
S: Stream (1 bit) - Server-push stream message
E: Encrypted (1 bit) - Payload is encrypted

3.2. Tier 0 Header (1 byte)

Tier 0 is used for messages tunneled inside an already-secure session. It provides minimal overhead.¶

 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0|0 0 0|C|S|E|
+-+-+-+-+-+-+-+-+

Tier 0 messages MUST only be sent within an established Tier 3+ session. Implementations receiving a Tier 0 message outside of a secure session MUST discard it.¶

3.3. Tier 1 Header (4 bytes)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V V|0 0 1|C|S|E|        Operation Code         |   Sequence    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Operation Code (16 bits)

Identifies the operation. See Section 6.¶

Sequence (8 bits)

Message sequence number, wrapping at 255.¶

3.4. Tier 2 Header (6 bytes)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V V|0 1 0|C|S|E|        Operation Code         |   Sequence    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Session ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Session ID (16 bits)

Identifies the session context for this message.¶

Tier 2 messages SHOULD include a CRC-16 trailer for error detection.¶

3.5. Tier 3 Header (12 bytes)

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V V|0 1 1|C|S|E|        Operation Code         |   Sequence    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Session ID           |           Timestamp           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Timestamp (cont.)        |             Nonce             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Timestamp (32 bits)

Unix timestamp in seconds. Used for replay protection.¶

Nonce (16 bits)

Random nonce component. Combined with timestamp and counter to form the full 96-bit nonce for ChaCha20-Poly1305.¶

Tier 3 messages with the E flag set MUST be encrypted using ChaCha20-Poly1305 as specified in [RFC8439].¶

3.6. Tier 4 Header (14 bytes)

Tier 4 carries the messages that establish a session (SESSION_INIT, SESSION_ACK). Earlier drafts of this document carried the 32-byte X25519 ECDH public key inline in a 42-byte header. With the move to a hybrid post-quantum KEX the key material grew to 1184 bytes (ML-KEM-768 encapsulation key) plus 1088 bytes (ML-KEM-768 ciphertext) plus the existing 32 bytes of X25519 per direction, which no longer fits in any sensibly-sized fixed header. Consequently, Tier 4 headers no longer carry KEX material inline; all public keys and ciphertexts are transported in the SESSION_INIT / SESSION_ACK payloads (see Section 7.1), and the header retains only session and nonce identifiers.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V V|1 0 0|C|S|E|        Operation Code         |   Sequence    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Session ID           |           Timestamp           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Timestamp (cont.)        |             Nonce             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Key ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Key ID (32 bits)

Identifier for the session key being used or negotiated. Zero during the initial SESSION_INIT before a key has been established.¶

3.7. Tier 5 Header (14 bytes + Poly1305 Tag)

Tier 5 uses the same 14-byte header as Tier 4 but appends a full Poly1305 authentication tag after the header (before the payload):¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    [Tier 4 Header - 14 bytes]                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   Poly1305 Tag (16 bytes)                     |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Prior drafts of this document mandated an additional HMAC-SHA256 trailer on Tier 5 as a post-quantum resilience workaround against potential future quantum attacks on Poly1305. With hybrid ML-KEM-768 key establishment now baked into Tier 4/5 (see Section 5), that trailer is redundant and has been removed. Implementations conforming to this draft MUST NOT emit an HMAC-SHA256 trailer on Tier 5 messages.¶

3.8. Request Correlation (Version 1)

Version 0 of the protocol correlates responses to requests by Operation Code. This limits each connection to one outstanding request per Operation Code, preventing parallel requests for the same operation (e.g., multiple concurrent thumbnail fetches).¶

Version 1 extends each tier-specific header with a 32-bit Request ID field, inserted after the tier-specific fields and before the payload. The Version field in the Flags byte (bits 0-1) distinguishes V0 from V1.¶

Example: Tier 1 Version 1 Header (8 bytes):¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1|0 0 1|C|S|E|        Operation Code         |   Sequence    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Request ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Header sizes by version:¶

5.1. Hybrid Key Exchange

Tier 4+ sessions establish a shared symmetric key using a hybrid construction that combines classical X25519 ECDH [RFC7748] with post-quantum ML-KEM-768 [FIPS203]. The hybrid output is secure as long as at least one of the two primitives remains unbroken: an adversary that eventually breaks X25519 (e.g. by running Shor's algorithm on a cryptographically relevant quantum computer) still has to defeat ML-KEM, and vice versa.¶

ML-KEM-768 (NIST category 3, approximately AES-192-equivalent security) is the default parameter set. ML-KEM-1024 MAY be offered by implementations requiring higher security margin; ML-KEM-512 is NOT RECOMMENDED for new deployments.¶

The initiator generates an ephemeral X25519 key pair and an ephemeral ML-KEM-768 decapsulation key pair, and sends both public keys in SESSION_INIT (see Section 7.1). The responder generates its own ephemeral X25519 key pair, encapsulates against the initiator's ML-KEM encapsulation key to obtain the PQ shared secret and its ciphertext, and returns the X25519 public key together with the ML-KEM ciphertext in SESSION_ACK.¶

Both sides then compute the combined shared secret:¶

ss_classical = X25519(local_x25519_priv, remote_x25519_pub)

; Responder: (ct, ss_pq) = ML-KEM-768.Encapsulate(initiator_mlkem_pub)
; Initiator: ss_pq       = ML-KEM-768.Decapsulate(local_mlkem_priv, ct)

combined_secret = ss_classical || ss_pq   ; 32 + 32 = 64 bytes

transcript_hash = SHA-256(
    SESSION_INIT_bytes  ||
    SESSION_ACK_bytes
)

session_key = HKDF-SHA256(
    IKM  = combined_secret,
    salt = nonce_initiator || nonce_responder,
    info = "myclerk-session-v1-hybrid" || transcript_hash,
    L    = 32
)

The concatenation order ss_classical || ss_pq is fixed and normative. Implementations that swap the order derive a different session key and will fail to communicate; this is a deliberate fail-closed property, not a bug.¶

The transcript_hash folded into the HKDF info parameter binds the session key to the exact bytes of the handshake as observed by the deriving endpoint. An on-path attacker who modifies any handshake field -- stripping a capability, downgrading kex-mode, swapping nonces, altering any declared parameter -- causes the two endpoints to derive different session keys, and the first post-handshake Tier 3 or Tier 5 frame fails its AEAD check. See Section 10.6 for the full security argument.¶

5.2. Classical-only Key Exchange (Legacy / Constrained)

Implementations that cannot afford the ~2.3 KB of wire overhead of the hybrid handshake (e.g. ESP32-class devices on low-bandwidth modem links, or legacy clients predating this draft) MAY negotiate classical-only mode by omitting the ML-KEM fields from SESSION_INIT and signalling kex-mode: classical-only. The responder MUST either accept and mirror classical-only in SESSION_ACK, or refuse the session if local policy requires PQ.¶

In classical-only mode the derivation reduces to:¶

combined_secret = X25519(local_x25519_priv, remote_x25519_pub)

transcript_hash = SHA-256(SESSION_INIT_bytes || SESSION_ACK_bytes)

session_key = HKDF-SHA256(
    IKM  = combined_secret,
    salt = nonce_initiator || nonce_responder,
    info = "myclerk-session-v1-classical" || transcript_hash,
    L    = 32
)

The info string intentionally differs between hybrid and classical-only derivations so that a key produced in one mode cannot be mistaken for a key in the other mode -- a domain-separation precaution against cross-protocol attacks.¶

Classical-only sessions MUST NOT be used for data requiring long-term confidentiality (conservatively: more than 10 years), because an attacker who records the traffic today and gains access to a cryptographically relevant quantum computer later can recover the session key. Implementations SHOULD log classical-only negotiations for audit purposes.¶

5.3. Key Rotation

Keys MUST be rotated after any of the following conditions:¶

• 2^32 messages sent (nonce exhaustion)¶
• 24 hours elapsed (time-based)¶
• Explicit KEY_ROTATE operation received¶

Rotated keys are derived as:¶

new_key = HKDF-SHA256(
    IKM  = current_key,
    salt = "rotate",
    info = rotation_counter (4 bytes, big-endian),
    L    = 32
)

6.1. Core Operations (0x0000-0x00FF)

6.2. Standard Operations (0x0100-0x01FF)

Standard Operations cover authentication, device registration, messaging, and identity management. The 0x0100-0x018F range is defined for authentication, key exchange, sessions, device registration, backup codes, and messaging. The 0x0190-0x01EF range is allocated to identity management operations.¶

6.3. Resource Sharing Operations (0x0200-0x02FF)

Resource Sharing operations enable devices to expose and consume resources across the network. These operations support video, audio, HID, and GPU services.¶

6.4. Hardware Passthrough Operations (0x0600-0x06FF)

Hardware Passthrough operations enable low-level access to hardware interfaces. Unlike service-based resource sharing, these operations provide direct protocol-level access to hardware buses.¶

6.5. Telephony: SMS Gateway (0x0B50-0x0B7F)

The SMS Gateway operations provide application-level SMS handling for the MyClerk platform. Unlike the low-level GSM Modem operations which deal with AT commands and hardware, these operations provide intelligent message routing, TAN/OTP detection, and emergency fallback services. These are standard protocol operations in the Telephony category (0x0B00-0x0BFF).¶

6.6. Application Operations (0x0700-0x1DFF)

Application-layer operations covering knowledge management, settings, messaging, telephony, calendar, tasks, smart home, automation, AI assistant, synchronization, orchestration, presence, health, location, plugins, MDM, legal documents, mobility, travel, audit, audio pipeline, and desktop client operations are defined in the companion document [MYCLERK-OPS].¶

The companion document serves as the authoritative registry for all application-layer operation codes in the 0x0700-0x1DFF range, following the "Assigned Numbers" pattern established by Bluetooth SIG specifications. This separation allows the core protocol specification to remain stable while application operations evolve independently.¶

7.1. SESSION_INIT Payload

The initiator MUST always include its X25519 public key. It SHOULD additionally include its ML-KEM-768 encapsulation key (and set kex-mode: hybrid-mlkem768) to negotiate the hybrid post-quantum KEX. If the initiator cannot afford the 1184-byte ML-KEM public, it MAY omit mlkem-public and set kex-mode: classical-only; servers that require PQ by policy will refuse such a session.¶

session-init = {
    nonce: bstr .size 8,
    timestamp: uint,
    kex-mode: kex-mode-type,
    x25519-public: bstr .size 32,
    ; mlkem-public REQUIRED when kex-mode = hybrid-mlkem768
    ? mlkem-public: bstr .size 1184,
    ? capabilities: [* capability],
    ? device-id: bstr .size 16,
}

kex-mode-type = &(
    classical-only:    0,  ; X25519 only (legacy / constrained)
    hybrid-mlkem768:   1,  ; ML-KEM-768 + X25519 (default)
    ; 2 reserved for future hybrid-mlkem1024
)

capability = &(
    compression-lz4:     0,
    compression-zstd:    1,
    encryption-chacha20: 2,
    encryption-aes256gcm:3,
    fragmentation:       4,
    streaming:           5,
    federation:          6,
    vfs:                 8,
    request-correlation: 11,
    pq-mlkem768:         12, ; signals ML-KEM-768 support
)

7.2. SESSION_ACK Payload

The responder MUST echo a selected-kex-mode. When that mode is hybrid-mlkem768, the responder MUST include mlkem-ciphertext: the 1088-byte ML-KEM ciphertext produced by encapsulating against the initiator's encapsulation key.¶

session-ack = {
    session-id: uint .size 2,
    nonce: bstr .size 8,
    selected-tier: uint .le 5,
    selected-kex-mode: kex-mode-type,
    x25519-public: bstr .size 32,
    ; mlkem-ciphertext REQUIRED when
    ; selected-kex-mode = hybrid-mlkem768
    ? mlkem-ciphertext: bstr .size 1088,
    ? selected-capabilities: [* capability],
}

7.3. SESSION_RESUME Payload

session-resume = {
    old-session-id: uint .size 2,
    ticket: bstr .size 64,
}

; Ticket structure (encrypted with server key, AES-256-GCM):
; - session-key: 32 bytes
; - device-id: 16 bytes
; - issued-at: 4 bytes (Unix timestamp)
; - expires-at: 4 bytes (Unix timestamp)
; - ticket-nonce: 8 bytes

8.1. Minimum Tier Requirements

The following operations have minimum tier requirements:¶

9.1. Specific Error Codes

0x00 OK

Operation completed successfully.¶

0x10 BAD_REQUEST

Malformed message or invalid parameters.¶

0x11 UNAUTHORIZED

Authentication required or failed.¶

0x12 FORBIDDEN

Insufficient permissions or tier.¶

0x13 NOT_FOUND

Requested resource does not exist.¶

0x17 INVALID_SESSION

Session expired or invalid.¶

0x20 INTERNAL_ERROR

Server encountered an unexpected error.¶

0x21 SERVICE_UNAVAILABLE

Service temporarily unavailable.¶

0x22 TIMEOUT

Operation timed out.¶

10.1. Nonce Reuse

Reusing a nonce with the same key in ChaCha20-Poly1305 completely compromises the confidentiality and authenticity of all messages encrypted with that key-nonce pair. Implementations MUST ensure nonces are never reused by:¶

• Using cryptographically random values for the Random field¶
• Maintaining a monotonic counter per session¶
• Rotating keys before counter exhaustion¶

10.2. Replay Protection

Tier 3+ messages include timestamps for replay protection. Implementations SHOULD reject messages with timestamps more than 5 minutes in the past or future. Session resumption tickets include a nonce that MUST be tracked to prevent replay attacks.¶

10.3. Tier Downgrade Attacks

An attacker might attempt to force communication at a lower tier. Servers MUST enforce minimum tier requirements for sensitive operations. Clients SHOULD warn users when connecting at a lower tier than expected.¶

10.4. Key Compromise

If a session key is compromised, an attacker can decrypt all messages in that session. The 24-hour automatic key rotation limits the window of exposure. For forward secrecy, implementations SHOULD use ephemeral ECDH keys for each session.¶

10.5. Post-Quantum Considerations

Tier 4 and Tier 5 sessions use hybrid post-quantum key establishment by default, combining ML-KEM-768 [FIPS203] with X25519 [RFC7748] via concatenation and HKDF-SHA256 extraction (see Section 5.1). The hybrid output remains secure as long as at least one of the two primitives does, which defeats both a future cryptographically relevant quantum computer (CRQC) running Shor's algorithm against X25519 and any currently unknown classical break of ML-KEM.¶

The symmetric layer (ChaCha20-Poly1305 with 256-bit keys) is considered post-quantum secure: Grover's algorithm reduces the effective key strength to 128 bits, which remains computationally infeasible to brute-force. No change to the symmetric primitive is required and none is prescribed.¶

Classical-only mode (kex-mode: classical-only) MAY be used by resource-constrained implementations (e.g. deeply embedded devices where the 1184-byte ML-KEM encapsulation key is infeasible over a low-bandwidth modem link) or for interoperability with legacy endpoints predating this draft. Classical-only mode MUST NOT be used for data requiring long-term confidentiality (conservatively, more than 10 years) due to store-now-decrypt-later attacks.¶

Implementations MUST NOT negotiate classical-only mode when at least one endpoint signals the pq-mlkem768 capability and local policy requires PQ for the session's intended use.¶

10.6. KEX Mode Downgrade Protection

Like tier negotiation (Section 10.3), KEX-mode negotiation is vulnerable to active on-path downgrade attempts. An attacker could strip mlkem-public from SESSION_INIT or remove the pq-mlkem768 capability to force classical-only. This draft binds the full handshake to the session key to make such modifications detectable.¶

Specifically, both endpoints fold a transcript hash of the complete SESSION_INIT and SESSION_ACK byte sequences into the HKDF-SHA256 info parameter during session key derivation (see Section 5.1). Any modification of any handshake field by an intermediary causes the two endpoints to observe different transcript hashes, derive different session keys, and fail AEAD verification on the first Tier 3 or Tier 5 frame. The domain separator strings "myclerk-session-v1-hybrid" and "myclerk-session-v1-classical" additionally prevent a hybrid-derived key from being confused with a classical-derived key of the same inputs.¶

Implementations MUST:¶

1. Include the exact wire-form bytes of SESSION_INIT and SESSION_ACK in the transcript hash, in the order they were sent.¶
2. Refuse to complete a session where the responder's selected KEX mode is weaker than the mode the initiator offered AND the local policy requires the stronger mode.¶
3. Log classical-only negotiations for audit purposes so operators can detect systemic downgrade attempts.¶

10.7. ML-KEM Implementation Hazards

ML-KEM-768 implementations MUST observe the following safety properties. These are standard Fujisaki-Okamoto precautions but are called out explicitly because ahistorical implementations have repeatedly failed at them.¶

1. Constant-time decapsulation. The decapsulation routine MUST run in time independent of the secret key and the ciphertext contents, to prevent timing side channels that can recover the private key over repeated queries.¶
2. Implicit rejection. On a ciphertext-validity failure, decapsulation MUST return a pseudo-random shared secret derived from the private key and the ciphertext (the Fujisaki-Okamoto transform's "implicit rejection" branch), NOT an error. Returning an error leaks ciphertext-validity information to the attacker.¶
3. Private-key hygiene. ML-KEM decapsulation private keys MUST be cleared from memory (e.g. via crypto/subtle.ConstantTimeCompare-adjacent zero-wipe helpers) once the session key has been derived and the ephemeral has no further use.¶

Implementations SHOULD use a well-reviewed library rather than implementing ML-KEM from scratch. In the Go ecosystem the standard library crypto/mlkem package (available since Go 1.24) satisfies all three requirements and is the RECOMMENDED choice; the liboqs project, BoringSSL's ML-KEM implementation, and libcrux are also suitable alternatives.¶

11.1. Service Name and Port Number Registration

IANA is requested to register the following service name and port number in the "Service Name and Transport Protocol Port Number Registry" [RFC6335]:¶

Service Name:

myclerk¶

Port Number:

5657¶

Transport Protocol(s):

TCP, UDP¶

Description:

MyClerk Protocol¶

Assignee:

IESG <iesg@ietf.org>¶

Contact:

IETF Chair <chair@ietf.org>¶

Reference:

This document¶

TCP is the primary transport for control messages, synchronization, authentication, and VFS operations. UDP is used for real-time streaming (video, audio) and low-latency sensor telemetry where latency is prioritized over reliability.¶

11.2. Operation Code Registry

IANA is requested to create a new registry titled "MyClerk Protocol Operation Codes" with the following structure:¶

Registration Procedure:

Expert Review per [RFC8126]¶

Reference:

This document¶

The initial entries are the operation codes defined in Section 6 of this document, organized into the following ranges:¶