Hi, On Wed, Jul 1, 2026 at 5:34 PM Gianfrancesco Aurecchia < [email protected]> wrote:
> Hi Jakub, > > Quick follow-up: > > Small change of plan from my last message: instead of validating for DTLS > 1.3 first, I used some free time these days to get a working 1.2 draft up. > DTLS turned out to be a bit trickier than I'd imagined, but something > sensible came out of it, and I'd really value your read on the direction > before I invest in 1.3 (which needs OpenSSL 4.1, still unreleased). If > you'd rather I sort out 1.3 first as I said, just tell me. > > So the reason why I mentioned to check DTLS 1.3 is because DTLSv1_listen is not currently supported there so it would be probably better to go through SSL_accept (with SSL_OP_COOKIE_EXCHANGE)). So the same should be used for DTLS 1.2 if possible. > I already have something you can build and test (branch below). In the > meantime let me walk you through the choices, and whenever you think it's > the right moment I'll prepare the draft PR. > > Approach > > A single 'dtls://' wrapper (plus 'dtlsv1.2://'), as you suggested, no > dedicated class. It lives in a self-contained 'xp_dtls.c': I don't touch > 'xp_ssl.c'. I reuse the naming and conventions of 'xp_ssl.c' as much as > possible (the 'GET_VER_OPT' macros, the 'sockop_*' handlers, the passphrase > callback, the same struct with 'php_netstream_data_t' as the first member), > so the file feels familiar to anyone who already knows 'xp_ssl' and the > review is quicker. But isolated: everyone's TLS path stays at zero risk and > the diff is small and reviewable. > > Another reason I didn't put it inside 'xp_ssl.c': that one belongs to the > TCP context (byte stream), while DTLS lives over UDP (datagrams). It's a > different transport context, so a dedicated file is its natural home. > > I can see the reasoning for separating but there seems to be lots of duplications so it might be good to have some xp_common.c with some shared helpers and restructure it a bit. But this can be probably added later. Makes sense to start with this and then we can see what could be shared. > Architectural choices > > In short: > > - Stream-only, no new PHP functions: just constants, context options and > metadata; everything goes through existing functions. > - Server: one peer per accepted socket, to avoid 'SO_REUSEPORT' (I'll > leave the multi-peer case to the offloading work, as you mentioned). > - Floor at DTLS 1.2 (1.0 is deprecated, RFC 8996). I'll add DTLS 1.3 > before the PR (I still have to get my hands on it), but I'd rather have > your feedback on the 1.2 setup first, so I don't invest in 1.3 on a base > you might want different. > - Session resumption: I plan to align with the RFC ( > https://wiki.php.net/rfc/tls_session_resumption_api) extending it to > DTLS. Here too I'll dive in after your first feedback, like for 1.3, so I > don't build on it before knowing whether the direction works for you. > It's not necessary but might be better to include it or at least research to get an idea about the whole design. > - 'local_cert'/'local_pk' as PEM file paths, consistent with 'tls://'. > > The only point worth expanding on is the core change: to make > 'enable_crypto' work over a 'udp://' (the way 'ext/openssl' overrides > 'tcp://' for TLS) you need the 'STREAM_CRYPTO_METHOD_DTLS_*' constants in > 'main/streams/php_stream_transport.h'. They're purely additive (no existing > logic touched) and it's the only point outside 'ext/openssl'. I've already > implemented it, but I'm not 100% sure it's the right approach: I'd lean > toward deferring it and keeping the first round to the 'dtls://' scheme > only (zero core), leaving the 'enable_crypto' over 'udp://' layer for > later. But if you take a look and it convinces you, all the better to keep > it in. > > The branch is here: > https://github.com/GianfriAur/php-src/tree/feature/openssl-dtls-stream > (branch 'feature/openssl-dtls-stream'). > > Please create a draft PR for this so we can discuss it there. It's much easier than here. > Where I'd like your input > > 1. The additive core touch for 'enable_crypto' over 'udp://': I've > implemented it but I'm not 100% sure it's fine. I'd lean toward deferring > it (first round 'dtls://' scheme only), but if you take a look and it > convinces you, all the better to keep it in. What do you think? > I guess it would be good to support so it's consistent but it's not necessary if it would be a pain to do. > 2. Does the 1.2 approach look right to you? (I'll add DTLS 1.3 and OpenSSL > 4.1 before the PR, I just wanted your OK on the direction before investing > in it.) > I haven't had time for a deep look but from what I see, the main issue might be usage DTLSv1_listen as I mentioned. I will try to check it out more next week and will comment on the PR. > 3. On certs/keys: do I stay on PEM paths like 'tls://', or is it worth > going for objects right away? > > Keep it consistent with tls to not over complicate it. > No rush given the summer, and honestly I won't be as lucky with free time > myself in the coming days either: I'll take my cue from your feedback > before formalizing anything. Thanks again for offering to take a look. > > I should be able to check in my short DTLS slot which I have every week (except holiday) around Friday. Kind regards, Jakub
