Merge pull request #10627 from julek-wolfssl/fenrir-fixes-20260601-dtls13-recv-epoch

F-5606: don't enforce DTLS 1.3 2^48-1 epoch cap on the receive side
This commit is contained in:
David Garske
2026-06-10 10:06:26 -07:00
committed by GitHub
2 changed files with 9 additions and 8 deletions
+5 -6
View File
@@ -12411,15 +12411,14 @@ static int DoTls13KeyUpdate(WOLFSSL* ssl, const byte* input, word32* inOutIdx,
#ifdef WOLFSSL_DTLS13
if (ssl->options.dtls) {
/* Increment on a local copy so ssl->dtls13PeerEpoch is left
* untouched when the check fails. */
w64wrapper newEpoch = ssl->dtls13PeerEpoch;
w64Increment(&newEpoch);
/* RFC 9147 Section 4.2.1: the epoch must not exceed 2^48-1. Reject a
* peer KeyUpdate that would advance the receiving epoch past the
* limit. Validate on a local copy so ssl->dtls13PeerEpoch is left
* untouched when the check fails. */
if (w64GT(newEpoch,
w64From32(DTLS13_EPOCH_MAX_HI32, DTLS13_EPOCH_MAX_LO32)))
/* RFC 9147 Section 8: the 2^48-1 cap is sender-only; receivers MUST
* NOT enforce it. Guard only the wrap-to-zero (Section 4.2.1). */
if (w64IsZero(newEpoch))
return BAD_STATE_E;
ssl->dtls13PeerEpoch = newEpoch;
+4 -2
View File
@@ -5961,8 +5961,10 @@ enum {
DTLS13_EPOCH_TRAFFIC0 = 3
};
/* RFC 9147 Section 4.2.1: the DTLS 1.3 epoch is a 48-bit value and must not
* exceed 2^48-1. Expressed as the high/low 32-bit halves of a w64wrapper. */
/* Sender-side DTLS 1.3 epoch ceiling: we MUST NOT advance our own epoch past
* 2^48-1 (RFC 9147 Section 4.2.1). This gates only the sending epoch; receivers
* MUST NOT enforce it on the peer epoch (RFC 9147 Section 8). Expressed as the
* high/low 32-bit halves of a w64wrapper. */
#define DTLS13_EPOCH_MAX_HI32 0x0000FFFFU
#define DTLS13_EPOCH_MAX_LO32 0xFFFFFFFFU