Telechat Review of draft-ietf-uta-tls13-iot-profile-23
review-ietf-uta-tls13-iot-profile-23-iotdir-telechat-sethi-2026-08-02-00

I am the assigned IoT-Directorate reviewer for this draft.

Review result: On the Right Track

Comments:
Section 3 discusses external PSKs and points to RFC 9258 for the importer
interface, but doesn't reference the companion RFC 9257 ("Guidance for External
Pre-Shared Key (PSK) Usage in TLS") which provides PSK entropy requirements and
the security properties that depend on them etc. For full disclosure, I am a
co-author of RFC 9257. Additionally, section 3 should include a pointer to
Appendix F.9 of RFC 9846 for cases when RPKs or self-signed certificates are
used as credentials. Basically to ensure usage of "external_id_hash" extension
in IoT deployments.

Section 4 (Error Handling) doesn't reference RFC 7925 section 6. Also a bit
unclear what guidance is carried forward. What about the new alerts in TLS 1.3
such as missing_extension or those that are removed in 1.3?

Section 5: Should there be no further guidance? Like how many and how often
servers should issue resumption PSKs. How they can save bandwidth and
computation in IoT deployments?

Section 6: "depending on the type of key confirmations". I am not sure I
understand what is meant here?

Section 11: clients MAY omit SNI when identity is established via "configured
IP address and port... or a raw public key". This can lead to the misbinding
attacks referenced in Appendix F.9 of RFC 9846. Maybe add a caution/reference.

Section 17.1.5 says that CA and subordinate CA can have finite validity period
even when the end-entity certificate itself is valid until 99991231235959Z.
While I agree that this should be allowed, many (or most) CA implementations
don't allow this. See for example:
https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html (child
CAs and end-entity certificates cannot outlive their parent certificates)

Section 17.1.7 says that "IoT deployments generally rely on short-lived
end-entity certificates". This is confusing with text preceding about
certificates that are valid till 99991231235959Z?

Section 17.4.1 could use perhaps better phrasing than "subject field is
lifted". Regarding "but the peer still learns the identifier" -> this is
obvious as the peer needs to know the identity being authenticated. I would
rather say "but the client identity/certificate is better protected as it is
sent only after the server certificate is received and validated". This could
also be added in section 23 (Privacy Considerations).

Section 19 could perhaps reference RFC 9191. They both essentially contain
similar guidance so not absolutely necessary. For full disclosure, I am a
co-author of RFC 9191.

Typos etc.:
Section 17.4.4: digitialSignature -> digitalSignature

Section 22: something is weird with the second part of the sentence:
"Deployments can use this mechanism as a migration path while PQC algorithms
are being introduced, at certificate-based authentication quantum resistant."