[RFC] STCP: secure-by-default transport (kernel-level, experimental)

[RFC] STCP: secure-by-default transport (kernel-level, experimental)

[Lauri Jakku]

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.
`-------------------------------------------------------------------->

Re: [RFC] STCP: secure-by-default transport (kernel-level, experimental)

[Jakub Kicinski]

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.

Re: [RFC] STCP: secure-by-default transport (kernel-level, experimental)

[Lauri Jakku]

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.
`-------------------------------------------------------------------->

Re: [RFC] STCP: secure-by-default transport (kernel-level, experimental)

[Jakub Kicinski]

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.