send.h File Reference

RFC 9001 5 / 5.1: seal server-direction outbound packets. More...

#include "common/bytes/span/span.h"
#include "tls/handshake/roles/server/server.h"

Go to the source code of this file.

Data Structures
struct	wired_srvloop_send_in
	Remaining arguments of wired_srvloop_send_initial/send_handshake/send_onertt beyond s and out: the connection id to write as the reply's DCID (the client's SCID, RFC 9000 7.2 — possibly zero-length; every send path writes it, send_initial's keys still come from the odcid recorded at boot), the packet number, the client packet to acknowledge (< 0 for none, unused by send_onertt), and the payload — a TLS flight to wrap in CRYPTO for Initial/Handshake, or the raw 1-RTT payload for send_onertt. More...

Functions
int	wired_srvloop_send_initial (const wired_server *s, const wired_srvloop_send_in *in, wired_obuf *out)
	Seal a ServerHello TLS flight into a server Initial packet, addressed to in->cli_scid (RFC 9000 7.2) and protected with the Initial keys derived from the odcid recorded at boot (RFC 9001 5.2).
int	wired_srvloop_send_initial_ver (u32 version, const wired_server *s, const wired_srvloop_send_in *in, wired_obuf *out)
	Same as wired_srvloop_send_initial, but the Initial keys, the header's Version field, and byte0's type bits all follow version (RFC 9369 3.2/3.3.1) – what accepting a client that already arrived speaking v2 replies with (RFC 9368 2: same version the peer used, no VN round trip).
int	wired_srvloop_send_handshake (const wired_server *s, const wired_srvloop_send_in *in, wired_obuf *out)
	Seal a Handshake TLS flight under SERVER_HS.
int	wired_srvloop_send_onertt (wired_server *s, const wired_srvloop_send_in *in, wired_obuf *out)
	Seal a raw 1-RTT payload (for example HANDSHAKE_DONE) under SERVER_AP.

Detailed Description

RFC 9001 5 / 5.1: seal server-direction outbound packets.

The server always seals with its own-direction keys: Initial keys for the ServerHello, SERVER_HS for the Handshake flight, SERVER_AP for 1-RTT payloads. The DCID written toward the client is the client's source id; the SCID is the server's iscid.

Function Documentation

wired_srvloop_send_handshake()

int wired_srvloop_send_handshake	(	const wired_server *	s,
		const wired_srvloop_send_in *	in,
		wired_obuf *	out )

Seal a Handshake TLS flight under SERVER_HS.

When in->ack_pn >= 0 the flight acknowledges that received Handshake-space packet number (RFC 9000 13.2.1).

Parameters

s	the server orchestrator holding the sealing keys
in	the reply DCID, packet number, ACK target, and TLS flight
out	receives the sealed packet

Returns

1 with out->len set, or 0 if the key is not derived or on overflow.

wired_srvloop_send_initial()

int wired_srvloop_send_initial	(	const wired_server *	s,
		const wired_srvloop_send_in *	in,
		wired_obuf *	out )

Seal a ServerHello TLS flight into a server Initial packet, addressed to in->cli_scid (RFC 9000 7.2) and protected with the Initial keys derived from the odcid recorded at boot (RFC 9001 5.2).

When in->ack_pn >= 0 the flight acknowledges that received client Initial packet number (RFC 9000 13.2.1); ack_pn < 0 sends CRYPTO only.

Parameters

s	the server orchestrator holding the sealing keys
in	the reply DCID, packet number, ACK target, and TLS flight
out	receives the sealed packet

Returns

1 with out->len set, 0 on overflow.

wired_srvloop_send_initial_ver()

int wired_srvloop_send_initial_ver	(	u32	version,
		const wired_server *	s,
		const wired_srvloop_send_in *	in,
		wired_obuf *	out )

Same as wired_srvloop_send_initial, but the Initial keys, the header's Version field, and byte0's type bits all follow version (RFC 9369 3.2/3.3.1) – what accepting a client that already arrived speaking v2 replies with (RFC 9368 2: same version the peer used, no VN round trip).

Returns

1 with out->len set, 0 on overflow or an unencodable version.

wired_srvloop_send_onertt()

int wired_srvloop_send_onertt	(	wired_server *	s,
		const wired_srvloop_send_in *	in,
		wired_obuf *	out )

Seal a raw 1-RTT payload (for example HANDSHAKE_DONE) under SERVER_AP.

in->ack_pn is unused (1-RTT sealing never ACKs). Counts the packet toward the AEAD confidentiality limit (RFC 9001 6.6) and, once the limit is reached, initiates a Key Update (6.1) before sealing – refusing instead while a previous self-initiated update is still unconfirmed (6.2).

Parameters

s	the server orchestrator holding the sealing keys
in	the reply DCID, packet number, and raw 1-RTT payload
out	receives the sealed packet

Returns

1 with out->len set, or 0 if the key is not derived, the AEAD limit forbids sealing, or on overflow.