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 <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] -- Thomas _______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
