]> git.ipfire.org Git - thirdparty/openssl.git/commit
Fix encryption level ordering
authorNeil Horman <nhorman@openssl.org>
Tue, 7 Jan 2025 14:12:03 +0000 (09:12 -0500)
committerNeil Horman <nhorman@openssl.org>
Wed, 8 Jan 2025 16:17:01 +0000 (11:17 -0500)
commit89e2c6f61ebbf2ee0b0b742eb66cba0583fc6813
treebd609403366e114a0c2beac7f2d192e17596f148
parent2457fc4816551a7e982117a4032fd1c259c493a7
Fix encryption level ordering

It was noticed recently that the enum for QUIC encryption levels doesn't
match the ordering that is outlined in the RFC.  RFC 9000 s. 12.2 and
RFC 9002 s 14.4.1 indicate that encryption level ordering is
INITIAL/0RTT/HANDSHAKE/1RTT, but our enum is in the order
INITAL/HANDSHAKE/0RTT/1RTT.

Our enum isn't a direct wire translation, so as long as the wire->enum
mapping done in ossl_quic_pkt_type_to_enc_level is done consistently it
ideally wouldn't matter, but because we do coalescing in
ossl_quic_tx_packetiser_generate by iterating through all the values in
the enum, its possible we may coalesce in the wrong order when we do
start implementing 0RTT support.

Fix it by adjusting the enum properly to match the RFC order.  This also
necessitates and adjustment to the archetypes array, which is a two
dimensional array indexed by encryption level and frame archetype
(PROBE/NORMAL/ACK ONLY).  Moving the 0RTT enc level to index 1 requires
moving the (formerly) index 2 0RTT array row to be at index 1.

Fixes #26324

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Saša Nedvědický <sashan@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/26334)
include/internal/quic_types.h
ssl/quic/quic_txp.c