Summary

  • On 3 September 2026, the IESG approved revision 25 of TLS/DTLS 1.3 Profiles for the Internet of Things as a Proposed Standard. The announcement did not yet assign a final RFC number.
  • The profile complements RFC 7925 and updates that TLS/DTLS 1.2 guidance only for its X.509 certificate profile and ciphersuite requirements. Long-lived legacy deployments do not disappear because a newer profile was approved.
  • The draft states the key limit itself: protocol compatibility is necessary but insufficient for interoperability at the authentication and authorization level.
  • Certificates, raw public keys and external PSKs create different provisioning and lifecycle duties. A successful handshake authenticates within one of those arrangements; local policy still decides whether the peer is the expected device and what it may do.
  • Operators should preserve a versioned authorization-boundary receipt joining credential mode, peer binding, permitted action, trust-anchor state, session age, reauthentication rule, error response and rollback. It can omit secrets and device-level personal data.

Approval settles a common floor

The IESG’s Protocol Action is a real standards decision. The document came from the Using TLS in Applications Working Group, received broad support and was approved for the Standards Track at Proposed Standard. It gives constrained implementations a shared account of TLS 1.3 and DTLS 1.3 credentials, extensions, error handling, session resumption, forward secrecy, timers, record sizes, certificates, cipher suites and privacy.

That common floor matters. A manufacturer and an operator cannot test interoperability when each silently chooses different mandatory extensions, credential semantics or certificate fields. The profile supplies a checklist and normative references. It also updates the certificate and ciphersuite portions of RFC 7925 while leaving that earlier TLS/DTLS 1.2 profile relevant for slow-moving industrial fleets.

Approval does not erase the profile’s own limits. Revision 25 says that TLS protocol compatibility is a required basis but is not enough to permit interoperability at the level of authentication and authorization. Those are not modest caveats attached after the technical work. They identify the handoff from a common protocol to a local decision system.

The RFC Editor may still make changes before publication, and the announcement did not supply a final RFC number. None of that weakens the approval. It simply keeps the document state accurate: approved Proposed Standard, not a published RFC and not an Internet Standard.

Three credential modes, three unfinished joins

The profile accommodates certificates, raw public keys and external pre-shared keys. It deliberately does not declare one mode universally correct. A deployment may choose among them according to security properties, operating constraints, cost and other factors.

A certificate can bind a public key to an identifier under an issuing chain. That proves neither that the identifier names the asset an operator intended to admit nor that the certificate’s holder may issue a command. Revision 25 distinguishes long-lived manufacturer-provisioned IDevIDs from operational LDevIDs, and concentrates its certificate guidance on the latter. The manufacturing identity may help bootstrap an operational credential. It is not a standing grant of operational privilege.

A raw public key removes certificate overhead but also removes a certificate’s naming structure. The document therefore requires the deployment to bind the authenticated key to the expected peer identity. When SNI is omitted because a deployment uses a pinned certificate, raw key, configured address or PSK identity, another binding is still required. Otherwise the technically authenticated key can be attached to the wrong peer expectation.

An external PSK moves more meaning into provisioning. Its identity, entropy, version separation and scope come from outside the handshake. The profile says PSK deployments should use ephemeral Diffie–Hellman where possible for forward secrecy. PSK-only operation is acceptable only when the loss of forward secrecy has been explicitly accepted for that deployment. A cryptographic option is therefore paired with a named governance act: somebody accepts the residual risk.

The common error is to call all three states “trusted”. The useful record is more exact: which key was authenticated, by which credential path, against which expected peer identity, for which application context, and under which current permission rule.

Revocation moves upward when the device cannot check

Constrained devices often lack the resources for conventional OCSP or certificate-revocation-list checks during the handshake. Revision 25 does not pretend that revoked credentials then cease to matter. It describes a different operating model: short-lived operational certificates, automated onboarding or management, and operator action to distribute replacements.

That alternative has a clock. An expired or replaced certificate does not automatically end an existing long-lived TLS session. TLS does not require continuous validity checking after connection establishment. If continuous validation is necessary, the application must actively reauthenticate the peer or tear down and re-establish the session. Mutual post-handshake authentication also needs application-protocol support through Exported Authenticators.

This is the article’s most consequential authority transfer. The constrained endpoint may omit a network revocation query, but the responsibility does not vanish. It rises to the operator, certificate manager and application that control credential lifetime, session lifetime and reconnection. A security inventory that records only the certificate expiry date misses the channel that can keep an earlier authentication alive.

Trust anchors have an even longer memory. Static anchors make CA rollover, algorithm transitions, manufacturer changes and incident response harder across devices that may remain deployed for years in inaccessible places. Firmware-update or certificate-management mechanisms can distribute new anchors, but distribution is not the same as activation. A fleet receipt needs to distinguish planned, delivered, installed, selected, observed and retired anchor generations.

Saving bytes creates local decisions

The profile is candid about resource costs. In its minimal mutual-authentication example using small elliptic-curve certificates and no subordinate CA, the two certificates account for about 40 percent of the handshake payload. Compact profiles, shallow chains, session resumption, certificate compression and caching can reduce the burden.

Each optimization changes another control. Session tickets reduce bandwidth and computation, while their count, lifetime and reuse policy must balance server state, replay and privacy. External certificate retrieval can reduce packets but add DNS or directory dependencies and expose stable identifiers. Caching saves retransmission but introduces invalidation. A smaller handshake is an operating result, not a free security upgrade.

The cleanest limit is 0-RTT. The profile says an application protocol must not use it without a protocol-specific profile that defines safe messages and fallback. At the time of revision 25, it says no such profile existed for CoAP or MQTT; this document therefore does not enable 0-RTT for them. Transport capability is not application permission.

Errors reveal the same division. An unattended industrial device cannot ask a user what to do with an alert. The application must decide whether to retry, choose another endpoint or credential, or enter a safe operational state. The TLS library reports a protocol condition. The operator owns the consequence.

A receipt for the authorization boundary

A useful receipt starts with the profile version and implementation build, but does not stop at a conformance result. It names the credential mode and stable credential reference; the expected peer identity and binding method; the application protocol and role; the local authorization-policy version; and the specific action class permitted or refused.

Its lifecycle block records trust-anchor generation, certificate or PSK generation, provisioning channel, activation evidence, scheduled expiry and replacement state. Its session block records full or resumed handshake, ticket generation, session start, last reauthentication and maximum allowed session age. If forward secrecy was intentionally forgone, the acceptance, owner, scope and expiry of that exception belong in the record.

Its safety block joins each material alert or validation failure to retry, alternate path, degraded mode or safe stop. It records whether 0-RTT is disabled, and if a later application profile enables it, which message classes and anti-replay state are covered. The receipt should record the decision and evidence, not secret keys, full certificates, exact private topology or a reusable attack path.

Correction must append rather than overwrite. When an anchor rotates, a certificate is replaced or a policy changes, the earlier state remains necessary to explain sessions opened under it. A current dashboard without history can say what is allowed now; it cannot explain why a device was admitted yesterday.

Heng Lu’s minimum-specification discipline is useful here in bounded form. The shared standard should state the smallest deterministic rules needed for interoperable transport. Future choices can remain local when their owner, input, decision and evidence are visible. The mistake is not local variation. It is an invisible local decision marketed as if the common standard made it.

What the approval does not prove

No reviewed source says that a named implementation conforms to revision 25, that any fleet has migrated, or that an incident occurred. The IESG did not certify a device, select a credential model or approve an operator’s permission table. A Proposed Standard is not a product badge.

The profile’s post-quantum section also stays within a clear boundary. Its normative ciphersuite recommendations use classical cryptography. The PQC discussion is informational and adds no new normative requirement. Long device lifetimes make migration planning urgent; they do not make this profile quantum-resistant.

Nor does the document say constrained devices can never perform revocation checks. It describes the common resource limitation and recommends an operator-mediated model, case by case. Capable devices and application requirements may justify different choices.

The approval is valuable because it narrows the common argument. Developers receive a stronger baseline. Operators receive a clearer list of decisions they still own. The durable governance result will come when those decisions are recorded with the same precision as the handshake.

Sources

  1. IESG — Protocol Action for the IoT TLS/DTLS 1.3 profile
  2. IETF — approved revision 25 of the IoT profile
  3. RFC 9846 — TLS 1.3
  4. RFC 9147 — DTLS 1.3
  5. RFC 7925 — TLS/DTLS profiles for IoT
  6. RFC 5280 — Internet X.509 PKI profile
  7. RFC 9257 — external PSK guidance
  8. RFC 9258 — importing external PSKs
  9. RFC 9019 — firmware updates for IoT devices
  10. RFC 8995 — BRSKI
  11. RFC 9525 — service identity in TLS
  12. RFC 9325 — secure use of TLS and DTLS
  13. Heng Lu — Minimum Initial Specification