From 4fa2a90219fb0504c7c7b6348d0c443df8649f55 Mon Sep 17 00:00:00 2001 From: Hannes Tschofenig Date: Fri, 23 Feb 2024 16:03:35 +0100 Subject: [PATCH] Long-lasting Connections --- draft-ietf-uta-tls13-iot-profile.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/draft-ietf-uta-tls13-iot-profile.md b/draft-ietf-uta-tls13-iot-profile.md index 1e651a8..b532e7c 100644 --- a/draft-ietf-uta-tls13-iot-profile.md +++ b/draft-ietf-uta-tls13-iot-profile.md @@ -407,14 +407,20 @@ mechanism to provision devices with new trust anchors. The use of device management protocols for IoT devices, which often include an onboarding or bootstrapping mechanism, has also seen considerable uptake in deployed devices and these protocols, some of which are standardized, -allow provision of certificates on a regular basis. This enables a +allow updates of certificates on a regular basis. This enables a deployment model where IoT device utilize end-entity certificates with shorter lifetime making certificate revocation protocols, like OCSP -and CRLs, less relevant. +and CRLs, less relevant. If TLS connections are long-lived a trigger +by the application layer is necessary to perform post-handshake authentication +to exchange the newly provisioned certificates. This will allow both peers +to learn about any certificate changes. TLS 1.3 provides basic +post-handshake client-to-server authentication only. Mutual +authentication via post-handshake messages is available via {{?RFC9261}} +but requires the application layer protocol to carry the payloads. Hence, instead of performing certificate revocation checks on the IoT device itself this specification recommends to delegate this task to the IoT device -operator and to take thenecessary action to allow IoT devices to remain +operator and to take the necessary action to allow IoT devices to remain operational. The CRL distribution points extension has been defined in RFC 5280 to