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

[Mohit Sethi <[e-mail]>]

Hi Thomas,

Hope you had a nice holiday and got a chance to rest and relax.

Commit/447e620 looks good to me and I have no further comments.

--Mohit

On 8/25/26 15:29, Thomas Fossati wrote:
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fthomas-fossati%2Fdraft-tls13-iot%2Fcommit%2F447e620&data=05%7C02%7Cmohit.sethi%40aalto.fi%7Cda7462f4fc9541d3247b08df02acf0dd%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C639232613954145349%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=snH3xRDZk7lvuv8iU1zN5KALDMAHjOfUIINw45TTym4%3D&reserved=0
> [2]https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-uta-tls13-iot-profile-24&data=05%7C02%7Cmohit.sethi%40aalto.fi%7Cda7462f4fc9541d3247b08df02acf0dd%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C639232613954193166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=L1r%2FGmw3lU2HjcoJaHHYsGNwK0BQbAVjX6R6wThJMIk%3D&reserved=0
>
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.aws.amazon.com%2Fprivateca%2Flatest%2Fuserguide%2Fca-lifecycle.html&data=05%7C02%7Cmohit.sethi%40aalto.fi%7Cda7462f4fc9541d3247b08df02acf0dd%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C639232613954222986%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Mmow7m1MCgsE3fNk8ueUjH3VkN1tcQcEVKkH9FW8%2BiI%3D&reserved=0 (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 [e-mail]
>
>
> --
> Thomas
>