* [RFC] STCP: secure-by-default transport (kernel-level, experimental) [not found] ` <c6cdc094-6714-437b-ba37-e3e62667f4aa@paxsudos.fi> @ 2025-12-22 18:13 ` Lauri Jakku 2026-01-02 23:49 ` Jakub Kicinski 0 siblings, 1 reply; 4+ messages in thread From: Lauri Jakku @ 2025-12-22 18:13 UTC (permalink / raw) To: Miguel Ojeda; +Cc: rust-for-linux, netdev STCP is an experimental, TCP-like transport protocol that integrates encryption and authentication directly into the transport layer, instead of layering TLS on top of TCP. The motivation is not to replace TCP, TLS, or QUIC for general Internet traffic, but to explore whether *security-by-default at the transport layer* can simplify certain classes of systems—particularly embedded, industrial, and controlled environments—where TLS configuration, certificate management, and user-space complexity are a significant operational burden. Key properties: * Connection-oriented, TCP-like semantics * Explicit cryptographic handshake during connection setup * Encrypted payloads handled at the protocol level * No plaintext fallback after handshake * Minimal configuration surface * Kernel-level implementation (Linux), primarily in Rust STCP currently uses: * ECDH-based key exchange * AEAD symmetric encryption (e.g., AES-GCM) * Explicit, length-prefixed record framing (64-bit BE length + IV + ciphertext) The project is implemented as a *real, running kernel module*, not a paper design. It is *experimental*, not production-ready, and not proposed as an Internet standard or upstream replacement. STCP does *not* aim to: * Replace TCP globally * Compete with TLS or QUIC for web traffic * Provide backward compatibility with existing TCP stacks Intended discussion points for netdev feedback: * Does this class of “secure-by-default transport” have valid kernel-level use cases? * Are the design trade-offs reasonable compared to TCP+TLS or QUIC? * Are there obvious architectural, security, or integration pitfalls? * Does this kind of experimentation belong in-kernel, and if so, how should it be structured? I got very interested parties (Big IoT companies and such) that wait for the module to mature. Full design RFC (including wire format) is available here: https://github.com/MiesSuomesta/STCP/blob/main/kernel/OOT/linux/RFC.md * * Feedback—critical or otherwise—is very welcome. --Lauri Jakku .---<[ Paxsudos IT / Security Screening ]>----------------------------------------------------------------> | Known viruses: 3626996 | Engine version: 1.4.3 | Scanned directories: 0 | Scanned files: 1 | Infected files: 0 | Data scanned: 0.00 MB | Data read: 0.00 MB (ratio 0.00:1) | Time: 12.668 sec (0 m 12 s) | Start Date: 2025:12:22 20:13:45 | End Date: 2025:12:22 20:13:57 | SPAM hints: [] | SPAM hints: [] | Message not from DMARC. `--------------------------------------------------------------------> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] STCP: secure-by-default transport (kernel-level, experimental) 2025-12-22 18:13 ` [RFC] STCP: secure-by-default transport (kernel-level, experimental) Lauri Jakku @ 2026-01-02 23:49 ` Jakub Kicinski 2026-01-05 15:38 ` Lauri Jakku 0 siblings, 1 reply; 4+ messages in thread From: Jakub Kicinski @ 2026-01-02 23:49 UTC (permalink / raw) To: Lauri Jakku; +Cc: Miguel Ojeda, rust-for-linux, netdev On Mon, 22 Dec 2025 20:13:40 +0200 Lauri Jakku wrote: > STCP is an experimental, TCP-like transport protocol that integrates > encryption and authentication directly into the transport layer, instead > of layering TLS on top of TCP. > > The motivation is not to replace TCP, TLS, or QUIC for general Internet > traffic, but to explore whether *security-by-default at the transport > layer* can simplify certain classes of systems—particularly embedded, > industrial, and controlled environments—where TLS configuration, > certificate management, and user-space complexity are a significant > operational burden. We tend to merge transport crypto protocol support upstream if: - HW integration is needed; or - some network filesystem/block device needs it. Otherwise user space is a better place for the implementation. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] STCP: secure-by-default transport (kernel-level, experimental) 2026-01-02 23:49 ` Jakub Kicinski @ 2026-01-05 15:38 ` Lauri Jakku 2026-01-05 23:45 ` Jakub Kicinski 0 siblings, 1 reply; 4+ messages in thread From: Lauri Jakku @ 2026-01-05 15:38 UTC (permalink / raw) To: Jakub Kicinski; +Cc: Miguel Ojeda, rust-for-linux, netdev Hi All, Jakub Kicinski kirjoitti 3.1.2026 klo 1.49: > On Mon, 22 Dec 2025 20:13:40 +0200 Lauri Jakku wrote: >> STCP is an experimental, TCP-like transport protocol that integrates >> encryption and authentication directly into the transport layer, instead >> of layering TLS on top of TCP. >> >> The motivation is not to replace TCP, TLS, or QUIC for general Internet >> traffic, but to explore whether *security-by-default at the transport >> layer* can simplify certain classes of systems—particularly embedded, >> industrial, and controlled environments—where TLS configuration, >> certificate management, and user-space complexity are a significant >> operational burden. > We tend to merge transport crypto protocol support upstream if: > - HW integration is needed; or > - some network filesystem/block device needs it. > Otherwise user space is a better place for the implementation. I got Nordic Semiconductor contact, that asked if it is upcoming feature for kernel, the need is there (For modem use). > .---<[ Paxsudos IT / Security Screening ]>----------------------------------------------------------------> > | Known viruses: 3627095 > | Engine version: 1.4.3 > | Scanned directories: 0 > | Scanned files: 1 > | Infected files: 0 > | Data scanned: 0.00 MB > | Data read: 0.00 MB (ratio 0.00:1) > | Time: 11.383 sec (0 m 11 s) > | Start Date: 2026:01:03 01:50:02 > | End Date: 2026:01:03 01:50:13 > | SPAM hints: [] > | SPAM hints: [] > | Message not from DMARC. > `--------------------------------------------------------------------> .---<[ Paxsudos IT / Security Screening ]>----------------------------------------------------------------> | Known viruses: 3627110 | Engine version: 1.4.3 | Scanned directories: 0 | Scanned files: 1 | Infected files: 0 | Data scanned: 0.00 MB | Data read: 0.00 MB (ratio 0.00:1) | Time: 12.740 sec (0 m 12 s) | Start Date: 2026:01:05 17:38:31 | End Date: 2026:01:05 17:38:43 | SPAM hints: [] | SPAM hints: [] | Message not from DMARC. `--------------------------------------------------------------------> ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] STCP: secure-by-default transport (kernel-level, experimental) 2026-01-05 15:38 ` Lauri Jakku @ 2026-01-05 23:45 ` Jakub Kicinski 0 siblings, 0 replies; 4+ messages in thread From: Jakub Kicinski @ 2026-01-05 23:45 UTC (permalink / raw) To: Lauri Jakku; +Cc: Miguel Ojeda, rust-for-linux, netdev On Mon, 5 Jan 2026 17:38:28 +0200 Lauri Jakku wrote: > Jakub Kicinski kirjoitti 3.1.2026 klo 1.49: > > On Mon, 22 Dec 2025 20:13:40 +0200 Lauri Jakku wrote: > >> STCP is an experimental, TCP-like transport protocol that integrates > >> encryption and authentication directly into the transport layer, instead > >> of layering TLS on top of TCP. > >> > >> The motivation is not to replace TCP, TLS, or QUIC for general Internet > >> traffic, but to explore whether *security-by-default at the transport > >> layer* can simplify certain classes of systems—particularly embedded, > >> industrial, and controlled environments—where TLS configuration, > >> certificate management, and user-space complexity are a significant > >> operational burden. > > We tend to merge transport crypto protocol support upstream if: > > - HW integration is needed; or > > - some network filesystem/block device needs it. > > Otherwise user space is a better place for the implementation. > > I got Nordic Semiconductor contact, that asked if it is upcoming > feature for kernel, the need is there (For modem use). Please come back once it's actually adopted and deployed somewhere. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-01-05 23:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <73757a9a-5f03-401f-b529-65c2ab6bcc13@paxsudos.fi>
[not found] ` <CANiq72mE5x70dg_pvM-n3oYY0w2mWJixxmpmrjuf_4cv2Xg8OQ@mail.gmail.com>
[not found] ` <ac4c2d81-b1fd-4f8f-8ad4-e5083ebc2deb@paxsudos.fi>
[not found] ` <22035087-9a3f-4abb-8851-9c66e835b777@paxsudos.fi>
[not found] ` <c6cdc094-6714-437b-ba37-e3e62667f4aa@paxsudos.fi>
2025-12-22 18:13 ` [RFC] STCP: secure-by-default transport (kernel-level, experimental) Lauri Jakku
2026-01-02 23:49 ` Jakub Kicinski
2026-01-05 15:38 ` Lauri Jakku
2026-01-05 23:45 ` Jakub Kicinski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).