PaperlayerView exact revision on arXiv

Source-linked AI summary

Post-Quantum Session Establishment for Matter over Thread: Message Size, Transport, and Protocol Options

Daniel Commey

arXiv:2610.13026v1cs.CRcs.NI

TL;DR

CASE still uses P-256 key exchange, leaving recorded traffic vulnerable to later decryption by a cryptographically relevant quantum computer; migrating it is constrained by Thread transport and Matter’s message limit. The paper models CASE message sizes and multi-hop transport, finding that no fully post-quantum configuration using FIPS 203/204/205 fits the limit and that fragmented IPv6 transport can trigger costly retransmissions.

  • Problem

    CASE still derives session keys from P-256, so recorded traffic can be decrypted later by a cryptographically relevant quantum computer, while Thread’s transport and Matter’s 1178-byte message limit complicate migration.

    Source: §I · p. 1

  • Method

    The paper models CASE message sizes across configurations and simulates multi-hop Thread transport using parameters from OpenThread and Matter source code.

    Source: §I · p. 1

  • Results

    A drop-in ML-KEM/ML-DSA handshake is 14 times larger than today’s, no fully post-quantum FIPS 203/204/205 configuration fits Matter’s 1178-byte limit, and fragmented IPv6 transport makes handshakes up to 2.6 times slower.

    Source: §XI · p. 8

  • Takeaways & Limitations

    Block transfer avoids the spurious retransmissions of fragmented IPv6 transport, while caching credential chains and using a pre-distributed ML-KEM key reduce a post-quantum handshake to 6.1 kB.

    Source: §V · p. 4, §XI · p. 8

    Latency findings come from a simulator that omits spatial reuse and other traffic, which overstates multi-hop transfer times and favors the timer effect at three or more hops.

    Source: C. Limitations · p. 7

Abstract

from arXiv · show

Matter's first post-quantum change protects device attestation with ML-DSA, but its operational handshake, CASE, still derives session keys from P-256 ECDH, so recorded traffic can be decrypted once a quantum computer exists. We quantify the cost of moving CASE to ML-KEM and post-quantum signatures over Thread, where frames carry at most 127 bytes and a Matter message at most 1178 bytes. A byte-exact model of the CASE messages shows that a drop-in ML-KEM-768/ML-DSA-44 handshake grows from 1.6 kB to 22.8 kB and that no fully post-quantum configuration built from FIPS 203/204/205 algorithms fits the message limit. A Monte Carlo model of multi-hop Thread, calibrated to OpenThread and Matter source constants, shows that sending these messages as fragmented IPv6 datagrams causes spurious retransmissions whenever a message and its reply outlast Matter's retransmission timer. At three to four hops the drop-in handshake then takes 1.8 to 2.6 times longer than with a selective-repeat block transfer, with or without interference, and up to 33% of handshakes with sleepy devices fail; raising the timers does not remove the effect. Caching certificate chains and authenticating the device with a pre-distributed ML-KEM key reduce the handshake to 6.1 kB and 44 ms of device computation. As a first step, hybrid P-256+ML-KEM-512 key exchange with a cached device chain protects session keys against harvest-now, decrypt-later attacks while every message still fits the current limit.

I. INTRODUCTION

CASE still uses P-256 ECDH for operational sessions, leaving recorded traffic vulnerable to later decryption by a quantum adversary. The paper quantifies post-quantum CASE size and transport costs, finding that no fully post-quantum FIPS 203/204/205 configuration fits the current message limit.

I. INTRODUCTION

  • P-256 ECDH-based CASE leaves recorded session traffic exposed to later decryption by a quantum adversary.The paper notes that smart-home devices may remain in service for a decade or more.Source: §I · p. 1
  • Matter’s first post-quantum change adds ML-DSA to commissioning attestation, but leaves CASE, operational certificates, and session keys unchanged.The larger attestation certificates are carried in 600-byte application-layer segments.Source: §I · p. 1
  • A byte-exact CASE size model covers 15 representative configurations and 3780 design points, with a TLV codec that round-trips all 19 reference certificate test vectors.The model is described as a contribution alongside the protocol-option evaluation.Source: §I · p. 1
  • No fully post-quantum CASE built from FIPS 203/204/205 algorithms fits a Matter message, so migration requires a transport change; a separate configuration offers harvest-now, decrypt-later protection without one.Source: §I · p. 1
  • Fragmented IPv6 transport triggers a timer pathology that makes CASE 1.8–2.6 times slower than block transfer at three or more hops.The Monte Carlo model uses link, mesh, sleepy-device, and retransmission parameters from OpenThread and Matter source code.Source: §I · p. 1
  • The introduction identifies sensitivity analyses over interference bursts, retransmission timers, and segment size, plus discussion of protocol-change security; all results are from models and simulation.The paper has not yet measured these results on hardware.Source: §I · p. 1

II. BACKGROUND

The background describes CASE’s message flow and credentials, then explains the Matter message-size limit and Thread’s constrained, fragmented radio transport.

A. CASE

  • CASE consists of Sigma1, Sigma2, Sigma3, and a status report, with each party verifying the peer’s certificate chain to the fabric root.Sigma2 and Sigma3 carry encrypted certificate and signature material; session resumption replaces them with a short Sigma2Resume.Source: A. CASE · p. 2

B. Message size limit

  • A Matter message over UDP is limited to 1178 B, while Thread devices do not normally support Matter’s TCP transport for larger payloads.The limit reserves room for IPv6 and UDP headers, Matter headers, and the message integrity code.Source: B. Message size limit · p. 2

C. Thread

  • Thread’s 127-byte MAC frames carry 96–101 B of IPv6 packet data, and a 1232-byte UDP payload occupies 13 frames.OpenThread retransmits unicast frames up to 15 times and discards a partially reassembled packet after 2 s; sleepy-device frames wait at the parent until polling.Source: C. Thread · p. 2

D. Matter reliable messaging

Matter reliable messaging uses whole-message acknowledgements and retransmissions, while the paper’s design space spans threat models, cryptographic choices, credentials, and caching.

D. Matter reliable messaging

  • MRP retransmits a whole reliable message using a retry timer whose interval grows with prior transmissions, and sends a standalone acknowledgement if none is piggybacked within 200 ms.OpenThread devices advertise a 2000 ms active retry interval and add a 1500 ms boost to their own timers; controllers on Wi-Fi or Ethernet advertise 300 ms.Source: D. Matter reliable messaging · p. 2

III. THREAT MODEL AND DESIGN SPACE

  • The design distinguishes harvest-now, decrypt-later protection from future active-quantum authentication and varies key exchange, chain signatures, chain structure, responder authentication, and cached credentials.The study enumerates 3780 combinations across these design dimensions.Source: §III · p. 2

IV. METHODOLOGY

The methodology builds byte-exact CASE encodings, estimates responder post-quantum computation, and simulates transport over multi-hop Thread under modeled loss and reliability behavior.

A. Message size model

  • The CASE TLV model replaces key and signature fields in reference certificate templates and re-encodes all 19 test vectors identically.Post-quantum certificate encodings are assumed because Matter has not specified them.Source: A. Message size model · p. 2

B. Computation model

  • Responder post-quantum computation counts operations around Sigma2 and Sigma3 using pqm4 Cortex-M4 cycle counts scaled to 64 MHz.Classical ECC is excluded, making the classical baseline slightly optimistic.Source: B. Computation model · pp. 2–3

C. Transport simulation

  • Per-frame simulation models CSMA-CA, airtime, acknowledgements, retries, fragmentation, mesh forwarding, sleepy-device polling, and MRP.Hops are traversed store-and-forward on one shared channel without spatial reuse, lengthening multi-hop transfers relative to a pipelined mesh.Source: C. Transport simulation · p. 3
  • Bursty loss uses four illustrative scenarios, and each scenario is run 300 times with independent seeds.The model reports medians with percentile-bootstrap 95% confidence intervals and the 90th percentile.Source: C. Transport simulation · pp. 3–4
  • Three larger-message transports are compared: IPv6 fragmentation, pull segmentation, and block transfer with bitmap-based selective retransmission.Segments carry 1,024 payload bytes and a 12-byte header unless stated otherwise.Source: C. Transport simulation · pp. 3–4
  • Piggybacked-ack arrival is estimated from loss-free first-unit delivery, underestimating spurious retransmissions under loss.The approximation therefore works against the reported timer effect.Source: C. Transport simulation · p. 4

V. MESSAGE SIZES

No fully post-quantum configuration using FIPS 203/204/205 algorithms fits Matter’s 1,178-byte message limit. Caching credentials can reduce message sizes, while hybrid P-256+ML-KEM-512 key exchange fits when the responder chain is cached.

V. MESSAGE SIZES

  • 22.8 kB in 244 frames makes drop-in ML-KEM-768/ML-DSA-44 (D3) 14 times the classical handshake size; composite hybrid certificates add 0.8 kB.The classical handshake is 1,576 B.Source: §V · p. 4
  • Removing the ICAC saves 7.7 kB, while short-signature roots shrink NOCs but require 4.9 kB or 66 kB root keys in device storage.KEM authentication replaces the responder’s 2,420-byte signature with a 1,088-byte ciphertext, which moves into Sigma3.Source: §V · p. 4
  • 2,459 B is the smallest largest message across 3,780 FIPS 203/204/205 design points, so no fully post-quantum configuration fits 1,178 B.The minimum uses ML-KEM with KEM-PDK and both chains cached.Source: §V · p. 4
  • Caching both chains and pre-distributing the device ML-KEM key yields a 6.1 kB handshake and 44 ms of device computation, versus 139 ms.The largest message is Sigma3 at 2,459 B, dominated by the controller’s ML-DSA-44 signature.Source: §V · p. 4
  • Hybrid P-256+ML-KEM-512 key exchange with a cached responder chain yields a 2.6 kB handshake with all messages within the limit.Using ML-KEM-768 instead makes cached-chain Sigma2 1,346 B, above the limit.Source: §V · p. 4
  • Making the ephemeral key optional reduces post-quantum resumption to 226 B total, below today’s 294 B, but adds a round trip when resumption fails.The reference implementation currently requires the ephemeral key in every Sigma1, including resumption attempts.Source: §V · p. 4

VI. TRANSPORT FOR LARGE MESSAGES

IPv6 fragmentation becomes the slowest transport for large handshakes from two hops onward, as MRP timers expire before fragmented replies arrive. Block transfer is faster in multi-hop D3 scenarios, while smaller C5 handshakes avoid the timer pathology.

Transport comparison

  • At three hops without interference, D3 takes 8.8 s with IPv6 fragmentation versus 4.9 s with block transfer; at four hops under heavy interference, it takes 32.3 s versus 13.1 s.The transport comparison is presented in Fig. 2.Source: Figure 2 · p. 5, §VI · p. 5

Timer interaction

  • At two hops, D3 has 1.0 spurious retransmissions per handshake and at four hops 3.8 without interference, as Sigma2's timer can expire before the Sigma3-carried acknowledgement arrives.Loss-free Sigma2 and Sigma3 delivery times make the timer condition hold from two hops; retransmitted Sigma2 further delays Sigma3.Source: §VI · p. 5, Figure 3 · p. 5

Transport comparison

  • Across 416 segmented-transport scenarios, pull segmentation is 5.9% slower at the median than block transfer, with the largest differences for sleepy devices.Each pull-segment request waits for a poll on sleepy devices.Source: §VI · p. 5

Smaller configuration

  • For C5, the largest message is 2.4 kB, the timer condition never holds, and IPv6 fragmentation is 7–9% faster than block transfer at all hop counts.The passage attributes spurious retransmissions to large handshakes.Source: §VI · p. 5

Sleepy devices

  • With oversized messages and a 200-ms poll interval under heavy interference, IPv6 fragmentation loses up to 33% of sleepy-device handshakes, while block transfer completes all 124,800 oversized-configuration handshakes.The fragmentation failures occur in Sigma3; pull segmentation loses one handshake across the oversized configurations.Source: §VI · p. 5

Radio time

  • At one hop without interference, device radio time is 1.15 s for D3, 318 ms for C5, and 85 ms for a classical handshake.For sleepy devices, handshake energy scales roughly with radio time; always-on routers keep their receiver on regardless.Source: §VI · p. 5

VII. SENSITIVITY

The transport comparison remains sensitive to interference, timer settings, and segment size. Fragmentation stays slower than block transfer across the tested timer settings at three and four hops, while smaller segments increase handshake time.

Interference

  • At three hops, IPv6 fragmentation is 2.1–2.8 times slower than block transfer across all 25 tested interference settings, and bursts of at least 60 ms can cause losses of up to 98% of handshakes.Pull segmentation stays within 16% of block transfer for bursts up to 30 ms, but is 1.3–2.0 times slower for 60–100 ms bursts occupying at least 20% of the time.Source: Figure 4 · p. 6, §VII · p. 6

Retransmission timers

  • At three and four hops, IPv6 fragmentation remains 2.0–2.5 times slower than block transfer across all nine tested timer settings.A 2-s controller interval and 3-s device boost remove the effect at two hops; longer timers also delay recovery from real losses.Source: §VII · p. 6, Figure 4 · p. 6

Segment size

  • Relative to 1150-byte segments, 300-byte segments are 27–41% slower and 600-byte segments are 3–12% slower.The added requests, MRP exchanges, and partially filled final frame account for the segment-size effect described in the passage.Source: §VII · p. 6

VIII. DESIGN-SPACE TRADE-OFFS

The explored design space trades handshake size against device computation. Among configurations using only FIPS 203/204/205 algorithms, C5 is the sole Pareto-optimal configuration reported.

Handshake size and computation

  • With FIPS 203/204/205 algorithms only, C5 with ML-KEM-512 is the sole Pareto-optimal configuration at 5.4 kB and 39 ms.Two Falcon-512 configurations also appear on the Pareto frontier: a 3.6-kB, 23-ms KEM-PDK variant and a 3.2-kB, 363-ms signature-based variant.Source: §VIII · p. 6

Segment-size comparison

  • Fig. 5 plots median handshake time with pull segmentation relative to 1150-byte segments across segment sizes.Source: Figure 5 · p. 6

Alternative signatures

  • Most MAYO, SNOVA, or UOV points are dominated because they require seconds of device signing or verification, or have very large public keys.The signature-size reductions do not offset those costs in most points.Source: §VIII · p. 6

IX. DISCUSSION

The protocol options trade handshake size and device computation against authentication and identity-protection properties. Certificate references can reduce transmission unless a receiver lacks the chain, while resumption without a KEM share adds no forward secrecy beyond the original session.

A. Security of the protocol options

  • The security analysis is informal; a formal treatment is left for future work.Source: A. Security of the protocol options · p. 6
  • C1’s hybrid P-256 and ML-KEM exchange protects against recorded traffic later decrypted by a quantum attacker, but not against an active quantum adversary.Source: A. Security of the protocol options · p. 6
  • C5 with ML-KEM-512 is the FIPS 203/204/205-only Pareto point (5.4 kB, 39 ms); Falcon-512 options reach 3.6 kB at 23 ms or 3.2 kB at 363 ms.The smaller KEM-PDK option uses a Falcon-512 key in the controller’s NOC with both chains cached; the signature-based option uses Falcon NOCs and both chains cached.Source: Figure 6 · p. 7
  • Plain KEM authentication lets an active attacker relay the device certificate and learn the controller’s identity, whereas KEM-PDK preserves SIGMA-I identity protection.KEM-PDK uses the responder’s known key in Sigma1 and key confirmation in Sigma2 before the initiator sends its certificate in Sigma3; the authors recommend it over plain KEM authentication.Source: A. Security of the protocol options · pp. 6–7
  • Certificate references are encrypted in Sigma2 or Sigma3; if the receiver lacks the chain, sending it costs a round trip but no security.Source: A. Security of the protocol options · p. 7
  • Resumption without a KEM share preserves the security of a successful resumption but adds no forward secrecy beyond the original session.Source: A. Security of the protocol options · p. 7

B. Recommendations

The recommendations stage the migration: first protect session keys with hybrid exchange and a cached device chain, then specify block transfer and post-quantum authentication. The estimates are model-based, with absolute latency less robust than transport comparisons.

B. Recommendations

  • Deploy hybrid P-256+ML-KEM-512 with a device-chain reference first; it protects against harvest-now, decrypt-later attacks without new transport, at 70 ms for one hop.Where policy requires ML-KEM-768, this step needs the transport change in step two.Source: B. Recommendations · p. 7
  • Specify windowed block transfer for secure-channel messages rather than relying on IPv6 fragmentation, and reuse it for PQC Phase 1 attestation certificates.Use segments as large as the message limit allows and bound the in-flight segment window to avoid overrunning small sender and router buffer pools.Source: B. Recommendations · p. 7
  • Specify post-quantum NOCs with chain references and KEM-PDK device authentication, and make the ephemeral share in resumption Sigma1 optional.The proposed fully post-quantum handshake is near 6 kB, with device computation below 50 ms.Source: B. Recommendations · p. 7

C. Limitations

  • Absolute latency estimates are model-dependent; transport ratios and their parameter sensitivity are more robust across settings.The simulator omits spatial reuse, other traffic, and memory, and does not evaluate TCP; default 5.6 kB buffer pools cannot hold a 10-kB Sigma message, while absolute times and device computation vary with hardware and assumptions.Source: C. Limitations · p. 7

X. RELATED WORK

Prior Matter-over-Thread work covers attestation or application performance, while related constrained-key-exchange, TLS, and low-power transfer studies leave aspects of large-message mesh transport open. The paper concludes that communication, rather than device computation, is the main cost of post-quantum CASE.

X. RELATED WORK

  • PQC Phase 1 covers Matter device attestation, while Matter-over-Thread measurement studies address application performance rather than security handshakes.Source: §X · p. 7
  • Post-quantum EDHOC suites and KEM-based authentication have been proposed, but their large-message transport over 802.15.4 mesh has not been studied.The paper states its message-size and transport results also apply to those approaches.Source: §X · p. 7
  • Prior TLS studies found larger post-quantum handshakes suffer disproportionately on lossy links; certificate caching and compression reduce TLS handshake size.Source: §X · pp. 7–8
  • CoAP block-wise transfer and Q-Block address large payloads on lossy constrained networks, and TCPlp showed TCP can perform well over Thread.Source: §X · p. 8

XI. CONCLUSION

  • A drop-in post-quantum CASE handshake is 14 times larger than today’s, and no FIPS 203/204/205-only configuration fits Matter’s 1178-byte message limit.The conclusion identifies communication on Thread as the main migration cost and device computation as secondary.Source: §XI · p. 8
Loading 2610.13026v1…