[WIP] DTLS 1.3 #38

xnorpx · 2026-01-03T03:37:17Z

POC

It passes some tests, but there is a lot needed here.

src/dtls13/engine.rs

tests/client-bssl.rs

src/client13.rs

xnorpx · 2026-01-03T03:49:31Z

Cargo.toml


 [dev-dependencies]
 openssl = { version = "0.10.70", features = ["vendored"] }
+boring = "4.19"


clean this up

algesten

I've been looking through the PR in detail. My gut feeling is that I underestimated just how different DTLS 1.3 is.

I'm totally on the fence on whether it should be co-mingled like it is in this PR, or whether we should just have dtls12, dtls13 as top level modules and accept some code duplication.

We can share buffer handling, crypto primitives etc.

xnorpx · 2026-01-03T17:12:18Z

I've been looking through the PR in detail. My gut feeling is that I underestimated just how different DTLS 1.3 is.
I'm totally on the fence on whether it should be co-mingled like it is in this PR, or whether we should just have dtls12, dtls13 as top level modules and accept some code duplication.

We can share buffer handling, crypto primitives etc.

Yes, I think I agree.

Let me do another iteration with those top level mods and then have common code flat and see how it looks.

But before I do that I want to figure out a way of adding boringssl for interop tests.

OpenSSL everything dtls 1.3 is still stuck in a branch so I think we start with boringssl that has it changes in master.

xnorpx · 2026-01-04T15:13:34Z

src/crypto/context13.rs

+//! Each epoch has its own traffic secrets derived via the TLS 1.3 key schedule.
+//!
+//! NOTE: This module is prepared for full DTLS 1.3 record layer integration.
+//! Some items are currently unused but will be connected in future work.


let's remove what is not used.

xnorpx · 2026-01-04T15:14:28Z

src/crypto/context13.rs

+    /// The AEAD cipher instance.
+    cipher: Box<dyn Cipher>,
+    /// Full 12-byte IV for nonce construction.
+    iv: Iv13,


Iv13 should we just move this to 1.3 mod?

xnorpx · 2026-01-04T15:17:30Z

src/crypto/context13.rs

+        let aad = Aad13::from_header(header_bytes);
+
+        // Decrypt in place using variable-length AAD for DTLS 1.3
+        let mut tmp = TmpBuf::new(ciphertext);


xnorpx · 2026-01-04T15:18:12Z

src/crypto/context13.rs

+        assert_eq!(ctx.send_epoch(), 0);
+        assert_eq!(ctx.recv_epoch(), 0);
+    }
+


More tests, check code coverage?

xnorpx · 2026-01-04T15:19:26Z

src/crypto/dtls_aead.rs

+    pub fn as_bytes(&self) -> &[u8] {
+        &self.data[..self.len]
+    }
+}


xnorpx · 2026-01-04T15:20:13Z

src/crypto/mod.rs


+    /// Extract SRTP keying material using TLS 1.3 exporter (RFC 8446 Section 7.5)
+    /// This is used for DTLS-SRTP with DTLS 1.3.
+    pub fn extract_srtp_keying_material_tls13(


xnorpx · 2026-01-04T15:21:14Z

src/crypto/provider.rs

+        info: &[u8],
+        out: &mut Buf,
+        output_len: usize,
+    ) -> Result<(), String>;


Should we use proper error handling here and not just "String" ?

xnorpx · 2026-01-04T15:22:26Z

src/crypto/tls13_key_schedule.rs

+    pub fn derive_application_secrets(
+        &mut self,
+        transcript_hash: &[u8],
+    ) -> Result<(Buf, Buf), String> {


Error instead of string

xnorpx · 2026-01-04T15:23:58Z

src/dtls13/client.rs

+type Dtls13CipherResult = Option<(Box<dyn crate::crypto::Cipher>, [u8; 12], [u8; 16])>;
+
+/// DTLS 1.3 client state machine.
+pub struct Client13 {


Should we tack on 13 on all these names or should we move them into this mod?

xnorpx · 2026-01-04T15:24:19Z

src/dtls13/client.rs

+impl Client13 {
+    pub(crate) fn new_with_engine(mut engine: Engine) -> Client13 {
+        engine.set_client(true);
+        engine.set_dtls13(true); // DTLS 1.3 transcript format


We have 2 different engines do we need this?

xnorpx · 2026-01-04T15:25:01Z

src/dtls13/client.rs

+            state: State::SendClientHello,
+            engine,
+            last_now: None,
+            local_events: VecDeque::new(),


I prefer default instead of new()

xnorpx · 2026-01-04T15:26:46Z

src/dtls13/client.rs

+        }
+        Ok(())
+    }
+


Make a comment about what test-helpers are for

xnorpx · 2026-01-04T15:27:40Z

src/dtls13/client.rs

+            server_version, cipher_suite
+        );
+
+        // In DTLS 1.3, the legacy version field is 0xFEFD (DTLS 1.2)


Add reference for this and why this is

xnorpx · 2026-01-04T15:29:34Z

src/dtls13/engine.rs

+
+    /// Schedule an immediate ACK (like BoringSSL's `schedule_ack()`).
+    /// Used when we want to ACK right away, e.g., after receiving client Finished.
+    #[allow(dead_code)]


Check why this ha s allow(dead_code)

xnorpx · 2026-01-04T15:30:11Z

src/dtls13/engine.rs

+        // delayed ACK when just acknowledging received data.
+        let delay = if self.has_gap_in_incoming_handshake() {
+            // Gap detected: immediate ACK to trigger fast retransmit
+            Duration::from_millis(0)


Duration::ZERO?

xnorpx · 2026-01-04T15:30:27Z

src/dtls13/engine.rs

+        } else {
+            // No gap: use RTO/4 delay for potential piggybacking
+            let rto = self.flight_backoff.rto();
+            if rto > Duration::from_millis(0) {


Duration::Zero

xnorpx · 2026-01-04T15:30:41Z

src/dtls13/engine.rs

+            if rto > Duration::from_millis(0) {
+                rto / 4
+            } else {
+                Duration::from_millis(0)


this whole logic looks funky, revisit

xnorpx · 2026-01-04T15:32:34Z

src/dtls13/incoming.rs

+invariants are later observed across a catch_unwind boundary. Marking Incoming
+as UnwindSafe is a sound assertion and clarifies behavior for callers.
+*/
+impl std::panic::UnwindSafe for Incoming {}


Revisit this

xnorpx · 2026-01-04T15:34:08Z

tests/client-wolfssl.rs

+    )
+}
+
+// =============================================================================


remove ===== comments everywhere

xnorpx · 2026-01-04T15:34:35Z

tests/client-wolfssl.rs

@@ -0,0 +1,1154 @@
+//! DTLS 1.3 interop tests: dimpl client <-> WolfSSL server


revisit new test files and see if we can make more code dry and reusable

xnorpx · 2026-01-04T15:35:10Z

tests/dtls13.rs

+//! These tests verify DTLS 1.3 handshake, encryption, SRTP keying material export,
+//! retransmission handling, and application data exchange.
+
+#![allow(unused)]


check allow here

xnorpx · 2026-01-04T15:35:23Z

tests/dtls13.rs

+}
+
+/// Helper to collect all outputs (packets and events) from an endpoint.
+fn drain_outputs(endpoint: &mut Dtls) -> DrainedOutputs {


helpers can be moved?

xnorpx · 2026-01-04T15:35:47Z

tests/server-wolfssl.rs

+    );
+}
+
+// NOTE: This test is commented out due to WolfSSL state machine quirks


don't leave dead code, cleanup

xnorpx · 2026-01-04T15:44:38Z

src/message/extensions/key_share.rs

+//! ClientKeyExchange messages from TLS 1.2.
+//!
+//! NOTE: This module is prepared for DTLS 1.3 but not yet fully integrated
+//! into the main extension parsing paths.


obsolete comment?

xnorpx · 2026-01-04T15:45:44Z

src/message/encrypted_extensions.rs

+//! contains extensions that don't need to be in the clear (everything except
+//! key_share, pre_shared_key, and supported_versions).
+//!
+//! NOTE: This module is prepared for DTLS 1.3 but not yet fully integrated


Is this Note still relevant?

xnorpx · 2026-01-04T15:46:03Z

src/message/extension.rs

 use std::ops::Range;

-#[derive(Debug, PartialEq, Eq, Default)]
+#[derive(Debug, Clone, PartialEq, Eq, Default)]


why was Clone added here?

xnorpx · 2026-01-04T15:47:05Z

src/message/handshake.rs

+        // to account for fragmentation across multiple records
+        const MAX_HANDSHAKE_LENGTH: u32 = 32 * 1024;
+        if header.length > MAX_HANDSHAKE_LENGTH {
+            return Err(nom::Err::Failure(Error::new(input, ErrorKind::TooLarge)));


looks quite verbose

xnorpx · 2026-01-04T15:49:16Z

src/message/parse_context.rs

+//! The `ParseContext` carries the negotiated DTLS version and enforces
+//! strictness rules to reject messages that are invalid for a given version.
+//!
+//! NOTE: This module is prepared for version-aware parsing but not yet


Search for all these NOTE:

xnorpx · 2026-01-04T15:50:27Z

src/message/record13.rs

@@ -0,0 +1,471 @@
+//! DTLS 1.3 Record Layer (RFC 9147)


should we ove record.rs and record13.rs to the mods?

xnorpx commented Jan 3, 2026

View reviewed changes

src/dtls13/engine.rs Show resolved Hide resolved

xnorpx commented Jan 3, 2026

View reviewed changes

tests/client-bssl.rs Outdated Show resolved Hide resolved

github-advanced-security bot found potential problems Jan 3, 2026

View reviewed changes

src/client13.rs Fixed Show fixed Hide fixed

src/client13.rs Fixed Show fixed Hide fixed

src/client13.rs Fixed Show fixed Hide fixed

src/client13.rs Fixed Show fixed Hide fixed

xnorpx commented Jan 3, 2026

View reviewed changes

algesten reviewed Jan 3, 2026

View reviewed changes

xnorpx force-pushed the dev/dtls13vibe branch 17 times, most recently from 634bf02 to ba7cc8e Compare January 4, 2026 05:48

This was referenced Jan 4, 2026

WARP Support in str0m algesten/str0m#809

Open

DTLS 1.3 #37

Open

xnorpx force-pushed the dev/dtls13vibe branch 5 times, most recently from 4738e5d to 62f88bb Compare January 4, 2026 06:25

xnorpx commented Jan 4, 2026

View reviewed changes

src/crypto/dtls_aead.rs

pub fn as_bytes(&self) -> &[u8] {

&self.data[..self.len]

}

}

Copy link

Collaborator Author

xnorpx Jan 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests?

xnorpx commented Jan 4, 2026

View reviewed changes

src/dtls13/client.rs

}

Ok(())

}

Copy link

Collaborator Author

xnorpx Jan 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make a comment about what test-helpers are for

xnorpx commented Jan 4, 2026

View reviewed changes

algesten force-pushed the main branch from 5704153 to b7bcb90 Compare February 2, 2026 10:05

		@@ -0,0 +1,1154 @@
		//! DTLS 1.3 interop tests: dimpl client <-> WolfSSL server

[WIP] DTLS 1.3 #38

Are you sure you want to change the base?

[WIP] DTLS 1.3 #38

Uh oh!

Conversation

xnorpx commented Jan 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

algesten left a comment

Choose a reason for hiding this comment

Uh oh!

xnorpx commented Jan 3, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

xnorpx commented Jan 3, 2026 •

edited

Loading