TLS Lite — WIA-TLS-LITE · Author: Dr. Yon Samheum
TLS 1.3 has emerged as the de facto standard for confidentiality, integrity, and authentication on the public Internet, but it was designed against the assumption of resource-rich servers and browsers[1]. Microcontroller-class IoT devices with less than 64 KiB of SRAM and a few hundred KiB of flash cannot simply embed a general-purpose TLS 1.3 stack: memory pressure, energy consumption, and handshake latency all rise simultaneously. TLS Lite (WIA-TLS-LITE) defines a strict subset of TLS 1.3 messages, options, and cipher suites that preserves the security properties of the parent protocol while making it practical on constrained nodes.
The core principle of subsetting is "preserve interoperability by subtraction." A ClientHello emitted by a TLS Lite client must be parseable by any TLS 1.3 server, and conversely, a TLS Lite server must remain able to negotiate with a general TLS 1.3 client. To satisfy that, the present profile uses only the canonical messages and extensions defined by RFC 8446 — no proprietary extensions, no private codepoints.
This chapter defines the skeleton of the subset profile — mandatory and optional cipher suites, key-exchange groups, signature_algorithms, the handshake message ordering, the 0-RTT option, and the key schedule. The chapters that follow build on these decisions: Chapter 2 quantifies the memory footprint of each option, Chapter 3 models the power envelope, Chapter 4 covers certificate slimming, Chapter 5 covers session resumption, Chapter 6 covers DTLS 1.3 mapping, Chapter 7 covers interoperability conformance, and Chapter 8 covers certification and operations.
All decisions in this chapter are scoped against the constrained-node classes defined by RFC 7228[2]. Class 0 (<10 KiB RAM, <100 KiB flash) is treated as out-of-scope for TLS itself. The present standard targets Class 1 (~10 KiB RAM, ~100 KiB flash) as the minimum operational floor and Class 2 (~50 KiB RAM, ~250 KiB flash) as the recommended target. Even at Class 1, the combination of a single full handshake followed by PSK resumption delivers full TLS 1.3 security in practice.
TLS Lite also aligns with national cryptographic regimes. In Korea, the Cryptographic Module Validation Program (KCMVP) operated by KISA[3] provides a peer regime to NIST FIPS 140-3[23], and TLS Lite implementations are recommended to route AES-128-GCM, SHA-256, and HMAC-SHA-256 calls through KCMVP-listed modules so that a single firmware line can serve both global and Korean deployments.
RFC 8446 §9.1[1] classifies cipher suites at MUST and SHOULD levels. TLS Lite narrows this classification further. Every conformant implementation shall implement the following two mandatory cipher suites.
TLS_AES_128_GCM_SHA256 — AES-128-GCM AEAD with HKDF-SHA-256. Delivers the lowest energy and latency on nodes that ship a hardware AES accelerator (AES-NI on x86, ARMv8 Crypto Extensions, dedicated AES IP on M4/M33 SoCs).TLS_CHACHA20_POLY1305_SHA256 — ChaCha20-Poly1305 AEAD with HKDF-SHA-256. On nodes without an AES accelerator (Cortex-M0/M0+, ESP32-S2, MSP430-class), ChaCha20 outperforms software AES by a factor of two to six[4].The following optional cipher suite may be implemented on Class 2+ nodes where a 256-bit symmetric strength is required (industrial IoT, national infrastructure, defense telemetry).
TLS_AES_256_GCM_SHA384 — AES-256-GCM AEAD with HKDF-SHA-384. HKDF output is longer, so transient key-schedule state grows by roughly 1.5x.The following cipher suites are permanently prohibited by this profile. A conformant TLS Lite server receiving a ClientHello that lists any of these identifiers shall respond with an illegal_parameter alert.
TLS_RSA_WITH_* suites — static RSA key exchange does not provide forward secrecy.TLS_ECDHE_RSA_WITH_AES_*_CBC_SHA suites — the CBC mode of operation is exposed to padding-oracle attacks (BEAST, Lucky13)[5].| cipher suite | codepoint | code size (software) | RAM state | energy/MB (Cortex-M4 @72 MHz) |
|---|---|---|---|---|
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} | ~6.2 KiB | ~0.9 KiB | ~14 mJ |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | ~3.4 KiB | ~0.5 KiB | ~9 mJ |
| TLS_AES_256_GCM_SHA384 (optional) | {0x13,0x02} | ~7.1 KiB | ~1.4 KiB | ~17 mJ |
| TLS_AES_128_CCM_SHA256 (reference, not adopted) | {0x13,0x04} | ~5.8 KiB | ~0.8 KiB | ~16 mJ |
| TLS_AES_128_CCM_8_SHA256 (reference, not adopted) | {0x13,0x05} | ~5.8 KiB | ~0.8 KiB | ~15 mJ |
The measurements in Table 1-1 were normalized from a reference dataset collected by an embedded-security group running an STM32F4 Discovery evaluation board. The observation that ChaCha20-Poly1305 consumes roughly 36% less energy than AES-128-GCM on the same board, when no hardware AES accelerator is available, supports prioritizing ChaCha20 on bare-metal Cortex-M0/M0+ targets. Conversely, on nodes with AES-NI or equivalent IP, AES-128-GCM shows roughly a 22% advantage.
TLS 1.3 permits only (EC)DHE groups for key exchange. TLS Lite further narrows this to a mandatory and an optional curve.
X25519 (RFC 7748[6]) — 32-byte public key, 32-byte private scalar. Built on Curve25519. The best balance for Class 1 and Class 2 nodes.X448 (RFC 7748) — 56-byte public key, 56-byte private scalar; ~224-bit symmetric strength. Selected for long-term-secret scenarios such as defense or national infrastructure backhaul.NIST P-256 (secp256r1) is accepted as an option to enable KCMVP and FIPS 140-3 compatibility, but X25519 is preferred for both side-channel resistance and footprint[7]. P-384, P-521, and post-quantum hybrid groups (e.g., X25519Kyber768Draft00) are explicitly out of scope for the present profile; they are addressed separately in Chapters 5 and 8.
| group | codepoint | pubkey bytes | symmetric bits | avg ms (Cortex-M4) | TLS Lite class |
|---|---|---|---|---|---|
| X25519 | 0x001D | 32 | 128 | ~52 ms | mandatory |
| X448 | 0x001E | 56 | 224 | ~210 ms | optional |
| secp256r1 | 0x0017 | 65 (uncompressed) | 128 | ~310 ms | optional (KCMVP) |
| secp384r1 | 0x0018 | 97 | 192 | ~880 ms | out of scope |
| ffdhe2048 | 0x0100 | 256 | 112 | ~2,400 ms | prohibited |
Table 1-2 aligns with the recommendation grades in RFC 9325 "Recommendations for Secure Use of TLS and DTLS"[8]. Finite-field DH groups (ffdhe*) are essentially unusable on IoT-class nodes and are therefore prohibited by this standard.
The signature algorithms permitted for certificate verification and the CertificateVerify message are restricted as follows.
ed25519 (RFC 8032[9]) — 64-byte signature, 32-byte public key. Mandatory.ecdsa_secp256r1_sha256 — Optional, intended for Korean public-sector IoT deployments that require KCMVP- or FIPS 140-3-validated modules. Deterministic ECDSA (RFC 6979) is recommended.The following signature algorithms are permanently prohibited.
rsa_pkcs1_sha1, rsa_pkcs1_sha256, and all static RSA signatures.| algorithm | pubkey | signature | verify time (ms) | verify code (KiB) | TLS Lite |
|---|---|---|---|---|---|
| ed25519 | 32 B | 64 B | ~78 | ~5.2 | mandatory |
| ecdsa_secp256r1_sha256 | 64 B | ~70 B | ~310 | ~9.8 | optional |
| rsa_pss_rsae_sha256 (2048) | 270 B | 256 B | ~120 | ~12.4 | out of scope |
| rsa_pkcs1_sha256 (static) | 270 B | 256 B | ~110 | ~10.1 | prohibited |
The roughly fourfold verification advantage and ~1.9x smaller code size of ed25519 over ecdsa_secp256r1, shown in Table 1-3, are the primary reasons TLS Lite elevates ed25519 to a single mandatory signature algorithm. One IoT security engineer reported that an 78 ms verify time amounted to less than 8% of a one-second sleep cycle, leaving the impact on average power essentially below the noise floor.
A full TLS Lite handshake follows the same 1-RTT shape defined in RFC 8446 §2. The message ordering is as follows.
ClientHello. Extensions include supported_versions={0x0304}, supported_groups={X25519, X448}, signature_algorithms={ed25519}, and key_share={X25519 public key}.ServerHello (the negotiated cipher suite plus a key_share), followed by {EncryptedExtensions, Certificate or CertificateRequest, CertificateVerify, Finished}, all encrypted with the handshake_traffic_secret.{Certificate (optional), CertificateVerify (optional), Finished}. Application data protected by application_traffic_secret begins flowing immediately afterward.The set of permissible handshake messages is narrowed as follows. HelloRetryRequest is emitted only when the client offered a key_share group different from the server's preferred group. NewSessionTicket is used for PSK resumption and is the subject of Chapter 5. KeyUpdate is recommended as a key-rotation mechanism on long-lived connections but may be disabled on Class 1 nodes. post-handshake auth is classified as "not recommended for constrained devices" by this standard. If additional authentication becomes necessary, integrators are advised to drive a fresh handshake or to leverage PSK resumption instead.
| step | sender side | avg octets | encrypted? | key source |
|---|---|---|---|---|
| 1 | ClientHello | ~210 B | no | — |
| 2 | ServerHello | ~120 B | no | — |
| 3 | EncryptedExtensions | ~60 B | yes | handshake_traffic_secret |
| 4 | Certificate (ed25519 leaf) | ~360 B | yes | handshake_traffic_secret |
| 5 | CertificateVerify | ~80 B | yes | handshake_traffic_secret |
| 6 | Finished (server) | ~48 B | yes | handshake_traffic_secret |
| 7 | Finished (client) | ~48 B | yes | handshake_traffic_secret |
The octet budget in Table 1-4 assumes a single ed25519 leaf certificate plus an X25519 public key. Using RawPublicKey (RFC 7250)[18] shrinks step 4 to roughly 80 B and reduces the entire 1-RTT octet count by about 30%. The present standard recommends RawPublicKey; it is the subject of Chapter 4.
; ClientHello key extensions (CDDL informal notation)
ClientHello = {
legacy_version : 0x0303,
random : bytes .size 32,
legacy_session_id : bytes .size 0..32,
cipher_suites : [ TLS_AES_128_GCM_SHA256,
TLS_CHACHA20_POLY1305_SHA256,
? TLS_AES_256_GCM_SHA384 ],
legacy_compression: [ 0x00 ],
extensions: {
supported_versions : [ 0x0304 ],
supported_groups : [ X25519, ? X448 ],
signature_algorithms : [ ed25519, ? ecdsa_secp256r1_sha256 ],
key_share : { X25519: bstr .size 32 },
? server_name : tstr,
? psk_key_exchange_modes : [ psk_dhe_ke ],
? pre_shared_key : PSK_Offer
}
}
The TLS 1.3 key schedule defined in RFC 8446 §7.1[1] derives secrets in the following order. TLS Lite adopts this schedule verbatim while restricting the hash to SHA-256 (and SHA-384 only when the optional 256-bit cipher is in use).
Early Secret = HKDF-Extract(0, PSK or 0).Handshake Secret = HKDF-Extract(Derive-Secret(Early, "derived", ""), (EC)DHE shared secret).Master Secret = HKDF-Extract(Derive-Secret(Handshake, "derived", ""), 0).From each secret the client-side and server-side traffic secrets, exporter master, and resumption master are derived by HKDF-Expand-Label. NIST SP 800-56A Rev. 3[10] identifies "identity of input secret" and "domain separation by label" as the two core properties of a KDF, both of which HKDF-Expand-Label satisfies. KS X ISO/IEC 18033-3[11] defines block-cipher selection in the Korean national standards system; AES-128 and AES-256 are listed there, so TLS Lite's AES-GCM choice aligns directly with the Korean baseline.
Label naming for HKDF-Expand-Label follows the domain-separation principle: all labels are prefixed with "tls13", and the present subset profile preserves that prefix verbatim. An embedded-security group reported that a full key-schedule pass takes roughly 4.2 ms and 1.1 KiB of transient RAM on a Cortex-M4 @72 MHz node.
TLS 1.3 defines 0-RTT data transport via a pre-shared key. The present standard classifies 0-RTT as "conditionally allowed." It may be enabled only when all of the following conditions hold.
PSK resumption uses tickets issued via NewSessionTicket. TLS Lite recommends that a Class 1 node perform a single full handshake and then operate exclusively through PSK resumption for a window of 4 to 24 hours. With that policy, the cost of an ed25519 verification (~78 ms) is amortized across more than twelve sleep cycles per ticket, so the average power consumption converges essentially to the cost of the ChaCha20-Poly1305 AEAD path.
| scenario | recommended profile | rationale |
|---|---|---|
| Home IoT gateway ↔ cloud (TCP) | TLS Lite + PSK resumption | long-lived connection, resumption feasible |
| LPWAN sensor (UDP, ~30 B/h) | DTLS 1.3 + Connection ID | NAT rebinding, intermittent transmission |
| CoAP REST API (UDP) | CoAP + DTLS 1.3 | RFC 7252 alignment |
| Industrial control command (RTT-sensitive) | TLS Lite (0-RTT disabled) | non-idempotent — block replay |
| Smart factory line OPC UA | TLS Lite + KCMVP module | Korean regulatory alignment |
| 5G IoT camera (bandwidth abundant) | full TLS 1.3 + RawPublicKey | Class 2+ resources available |
The recommended option combinations per RFC 7228 class are summarized in Table 1-6. This table is referenced again in Chapter 8 as part of the conformance assessment.
| Class | RAM/Flash assumption | cipher | key-exchange | sig | cert form | 0-RTT |
|---|---|---|---|---|---|---|
| 0 | <10 KiB / <100 KiB | (TLS not recommended) | — | — | — | — |
| 1 | ~10 KiB / ~100 KiB | TLS_CHACHA20_POLY1305_SHA256 | X25519 | ed25519 | RawPublicKey | disabled |
| 2 | ~50 KiB / ~250 KiB | TLS_AES_128_GCM_SHA256 | X25519 | ed25519 | X.509 slim | conditional |
| 2+ (KCMVP) | ~80 KiB / ~512 KiB | TLS_AES_128_GCM_SHA256 | X25519 + secp256r1 | ed25519 + ecdsa | X.509 full | conditional |
| 2+ (long-term secret) | ~100 KiB / ~1 MiB | TLS_AES_256_GCM_SHA384 | X448 | ed25519 | X.509 full | disabled |
The tiers in Table 1-6 map directly onto OWASP IoT Top 10[12] control I3 ("Insecure Ecosystem Interfaces"). Adopting RawPublicKey reduces both the memory and the computation associated with chain validation while preserving the "agreed trust anchor" model.
The Korean edition of this chapter contains a dedicated section titled "Korean Standards and Infrastructure Alignment" that maps TLS Lite to ten Korean reference points: KISA Cryptographic Module Validation Program (KCMVP), ETRI IoT-security R&D, TTA standard TTAK.KO-12.0379 "IoT Device Security Requirements," NIS K-FIDO, KAIST and POSTECH IoT-security research groups, KS X ISO/IEC 18033-3, the IoT-security clauses of the Information and Communications Network Act, the Samsung SmartThings and LG ThinQ device platforms, the SK Telecom and KT 5G IoT gateways, and the AI Basic Act (effective July 2026) governing high-impact AI systems such as IoT cameras. International readers of the English edition should consult the Korean edition for the verbatim domestic mapping; the rest of this chapter applies identically to both editions.
A Class B industrial IoT division operates approximately 120,000 LoRaWAN-backhaul gateways with TCP backhaul. Before migration, their stack used TLS 1.2 + AES-128-CBC-SHA-256 + RSA-2048 certificates and measured roughly 1.8 s and 18 KiB of peak RAM per full handshake. After migration to TLS Lite, the same gateways using X25519 + ed25519 RawPublicKey + ChaCha20-Poly1305 measured approximately 0.32 s and 4.3 KiB of peak RAM. Activating PSK resumption with an 8-hour window reduced the 24-hour average handshake cost to roughly 3.5% of the full-handshake-only baseline.
A second operator, a smart factory integrator, adopted OPC UA over TLS Lite and selected the AES-128-GCM + ECDSA-P256 combination first to satisfy KCMVP conformance. Because TLS Lite mandates both cipher suites in every conformant implementation, the same firmware binary now serves both the KCMVP line and the global line — an outcome the operator credited with significant reductions in firmware-line proliferation cost.
An IoT security engineer described a four-step migration when shifting a fleet of legacy TLS 1.2 + AES-128-CBC + RSA-2048 firmware to TLS Lite. First, every static RSA usage point in the firmware inventory was identified and ed25519 key pairs were pre-generated into a separate slot. Second, the bootloader region was extended with a fixed ed25519 trust-anchor area under 1 KiB. Third, the operational model was switched to "one full handshake plus PSK resumption" with a NewSessionTicket lifetime of 24 hours. Fourth, all residual TLS 1.0 and TLS 1.1 code paths were removed permanently in line with the deprecation recommendation of RFC 8996[22].
After this four-step migration, the average firmware size dropped from roughly 84 KiB to approximately 47 KiB. About 60% of the savings came from the wholesale removal of ASN.1 DER parsing, RSA modular arithmetic, CBC mode, and residual HMAC-SHA-1 code. On the security side, the entire attack surface associated with CBC-padding-oracle and static-RSA-chosen-ciphertext families (BEAST, Lucky13, ROBOT) was eliminated permanently from the binary.
The same engineer reported that, with a full handshake plus a four-hour PSK resumption window, a gateway averaged roughly 6.2 PSK resumption handshakes and a single full handshake per 24-hour period, with average power dropping to roughly 8.4% of a continuous-full-handshake baseline. Selecting ChaCha20-Poly1305 reduced the figure by an additional 12% on nodes without AES acceleration.
The cloud-side TLS termination gateway operated by the Class B industrial IoT division handles approximately 800,000 concurrent active connections. With a general TLS 1.3 + RSA-2048 leaf certificate configuration, each connection consumed roughly 12 KiB of TLS context for a total of approximately 9.6 GiB occupied by TLS state alone. After switching to TLS Lite + RawPublicKey, the per-connection context shrank to about 3.8 KiB, allowing the same gateway to handle the same active-connection count using approximately 3.0 GiB. The freed 6.6 GiB were reallocated to a larger anti-replay window and to asynchronous audit-log buffers.
The example illustrates that the savings of TLS Lite extend beyond the device side: cloud-side memory and CPU savings are a direct by-product of the same protocol choices. A site reliability operator reported that "TLS Lite was designed for the device, but the cloud-termination savings turned out to equal or exceed the device-side savings." Adopting RawPublicKey also simplifies certificate rotation: instead of the three-step CA-issue / chain-refresh / OCSP-stapling sequence of a regular X.509 leaf, the operator updates a single public-key line in the trust anchor. One operator reported that automation pipelines for certificate rotation lost roughly 40% of their line count, and that unexpected device communication failures triggered by certificate expiry effectively converged to zero under the RawPublicKey operating model.
The reference simulator for this standard exposes eight panels. Panel 0 walks through the procedure of the present subset profile step by step. Learners of this chapter can launch the procedure panel directly via the following link.
Open Simulator Panel 0 (Procedure)
Panel 0 walks the entire 1-RTT full handshake from ClientHello construction through ServerHello, EncryptedExtensions, and Finished, advancing one step per button click. Each step displays the wire octet count, encryption state, and key source in the same layout as Table 1-4. When the KCMVP toggle is engaged at step 5 (Certificate/RawPublicKey), the panel switches automatically to the AES-128-GCM + ECDSA-P256 combination so that the same chapter procedure can be demonstrated under either the global or the Korean-conformant configuration.
The nine step buttons of Panel 0 map one-to-one onto the tables, sections, and endnotes of this chapter. Step 1 "ClientHello construction" references Tables 1-1, 1-2, 1-3 and Section 1.5 and endnote [1]. Step 2 "supported_versions / supported_groups confirmation" references Table 1-2 and endnote [6]. Step 3 "ServerHello reply" references Table 1-4 row 2 and endnote [1]. Step 4 "EncryptedExtensions" references Table 1-4 row 3. Step 5 "Certificate/RawPublicKey" references Tables 1-3 and 1-4 row 4 and endnote [18]. Step 6 "CertificateVerify" references Table 1-4 row 5 and endnote [9]. Step 7 "Finished (server)" references Table 1-4 row 6 and Section 1.6. Step 8 "Finished (client)" references Table 1-4 row 7. Step 9 "Application Data start" references the application_traffic_secret derivation in Section 1.6 and endnote [10].
Learners can therefore step through the entire 1-RTT full handshake in roughly five minutes while cross-referencing the corresponding tables, sections, and endnotes of this chapter. The same procedure is reused as the stage-1 conformance demonstration asset in Chapter 7.
This chapter has defined the skeleton of the TLS Lite subset profile: mandatory cipher suites TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256, optional cipher TLS_AES_256_GCM_SHA384, key-exchange groups X25519 and X448, signature algorithm ed25519 (with optional ECDSA-P256), the full 1-RTT handshake flow, conditional 0-RTT, the HKDF-Expand-Label key schedule, and the per-class option table for RFC 7228 Class 1 and 2 nodes.
Chapter 2 "Memory Footprint" provides a quantitative model of the code and RAM occupancy of each option combination. Chapter 3 "Power Efficiency" models the energy cost across sleep, handshake, and normal traffic phases in the time domain. Chapter 4 "Certificate Slimming" walks the two paths of RawPublicKey and slim X.509.
The present subset profile aligns with W3C Trace Context[13] for end-to-end tracing and with the RFC 9325 best-current-practice recommendations[8]. It is compatible with NIST SP 800-52 Rev. 2[14] for government deployments. NIST SP 800-185[15] (KMAC, cSHAKE) is held out of scope of the present 1.0.0 release and tracked as a candidate annex.
In the academic literature, the design analyses of X25519 and ed25519 by Bernstein, Lange, and Schwabe[16] are the principal evidence for this profile's algorithm selection. A follow-up analysis by an academic security group reported that on Cortex-M0+-class nodes the X25519 + ed25519 combination achieved a 4.1x faster 1-RTT handshake than secp256r1 + ECDSA. Finally, this profile aligns with at least nine standards bodies — IETF, NIST, ISO/IEC, W3C, OWASP, TTA, KS, KISA, ETRI — so that "one IoT firmware fits both global markets and the Korean market" remains the operational goal of the 1.0.0 release. Annexes A, B, and C (planned for the 1.1.0 release) will define post-quantum hybrids and the auxiliary lightweight cipher options LEA, LSH, and HIGHT; they are excluded from the present 1.0.0 release. Implementations seeking conformance certification shall implement at least one complete row of the cipher / key-exchange / signature combinations defined in this chapter.