[Iot-directorate] Re: draft-ietf-uta-tls13-iot-profile-23 telechat Iotdir review

[Thomas Fossati <[e-mail]>]

hi Mohit,

Thank you very much for your careful review, and apologies for the
delayed response, which fell into the cracks of the usual post-IETF
chaos (including the co-authors' holidays).

We think we have addressed your points in this commit [1] which got
bundled in -24 [2].  Please let us know if you have any further
questions or comments.

cheers, thanks!

[1] https://github.com/thomas-fossati/draft-tls13-iot/commit/447e620
[2] https://author-tools.ietf.org/iddiff?url2=draft-ietf-uta-tls13-iot-profile-24

On Sun, Aug 2, 2026 at 9:41 PM Mohit Sethi via Datatracker
<[e-mail]> wrote:
>
> Document: draft-ietf-uta-tls13-iot-profile
> Title: TLS/DTLS 1.3 Profiles for the Internet of Things
> Reviewer: Mohit Sethi
> Review result: On the Right Track
>
> 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."
>
>
> --
> Iot-directorate mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



--
Thomas