Content-Type: multipart/alternative;
 boundary="------------wIhT3XPTQZidaslPkageUZFu"
Message-ID: <1690778e-196e-4a1d-a0f4-c7564d9d5dea@iki.fi>
Date: Tue, 25 Aug 2026 17:58:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Thomas Fossati <tho.ietf@gmail.com>
References: 
 <178569969705.1808983.15002430464726603888@dt-datatracker-d4d6ff9d9-ql5mb>
 <CAObGJnOzn=AKQtVj00_7jRC_HVf5D=u892jutAUUgoFEvpFJfw@mail.gmail.com>
Content-Language: en-US
From: Mohit Sethi <mohit@iki.fi>
In-Reply-To: 
 <CAObGJnOzn=AKQtVj00_7jRC_HVf5D=u892jutAUUgoFEvpFJfw@mail.gmail.com>
Message-ID-Hash: QN4XOI5D5ZWWHDSEYU4S2QEWL5AIKXQ6
CC: iot-directorate@ietf.org, draft-ietf-uta-tls13-iot-profile.all@ietf.org,
 last-call@ietf.org, uta@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BIot-directorate=5D_Re=3A_draft-ietf-uta-tls13-iot-profile-23_te?=
 =?utf-8?q?lechat_Iotdir_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/iot-directorate/DXaaRrfxO4IgkWNPHgPjCZmoTTA>

This is a multi-part message in MIME format.
--------------wIhT3XPTQZidaslPkageUZFu
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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
> <noreply@ietf.org> 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 --iot-directorate@ietf.org
>> To unsubscribe send an email toiot-directorate-leave@ietf.org
>
>
> --
> Thomas
>
--------------wIhT3XPTQZidaslPkageUZFu
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
  </head>
  <body>
    <p>Hi Thomas,</p>
    <p>Hope you had a nice holiday and got a chance to rest and relax.</p=
>
    <p>Commit/447e620 looks good to me and I have no further comments.</p=
>
    <p>--Mohit</p>
    <div class=3D"moz-cite-prefix">On 8/25/26 15:29, Thomas Fossati wrote=
:<br>
    </div>
    <blockquote type=3D"cite"
cite=3D"mid:CAObGJnOzn=3DAKQtVj00_7jRC_HVf5D=3Du892jutAUUgoFEvpFJfw@mail.=
gmail.com">
      <pre wrap=3D"" class=3D"moz-quote-pre">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] <a class=3D"moz-txt-link-freetext" href=3D"https://eur01.safelinks.pr=
otection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fthomas-fossati%2Fd=
raft-tls13-iot%2Fcommit%2F447e620&amp;data=3D05%7C02%7Cmohit.sethi%40aalt=
o.fi%7Cda7462f4fc9541d3247b08df02acf0dd%7Cae1a772440414462a6dc538cb199707=
e%7C1%7C0%7C639232613954145349%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn=
RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3=
D%7C0%7C%7C%7C&amp;sdata=3DsnH3xRDZk7lvuv8iU1zN5KALDMAHjOfUIINw45TTym4%3D=
&amp;reserved=3D0">https://eur01.safelinks.protection.outlook.com/?url=3D=
https%3A%2F%2Fgithub.com%2Fthomas-fossati%2Fdraft-tls13-iot%2Fcommit%2F44=
7e620&amp;data=3D05%7C02%7Cmohit.sethi%40aalto.fi%7Cda7462f4fc9541d3247b0=
8df02acf0dd%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C6392326139541453=
49%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl=
AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3Ds=
nH3xRDZk7lvuv8iU1zN5KALDMAHjOfUIINw45TTym4%3D&amp;reserved=3D0</a>
[2] <a class=3D"moz-txt-link-freetext" href=3D"https://eur01.safelinks.pr=
otection.outlook.com/?url=3Dhttps%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%=
3Furl2%3Ddraft-ietf-uta-tls13-iot-profile-24&amp;data=3D05%7C02%7Cmohit.s=
ethi%40aalto.fi%7Cda7462f4fc9541d3247b08df02acf0dd%7Cae1a772440414462a6dc=
538cb199707e%7C1%7C0%7C639232613954193166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB=
0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU=
IjoyfQ%3D%3D%7C0%7C%7C%7C&amp;sdata=3DL1r%2FGmw3lU2HjcoJaHHYsGNwK0BQbAVjX=
6R6wThJMIk%3D&amp;reserved=3D0">https://eur01.safelinks.protection.outloo=
k.com/?url=3Dhttps%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-=
ietf-uta-tls13-iot-profile-24&amp;data=3D05%7C02%7Cmohit.sethi%40aalto.fi=
%7Cda7462f4fc9541d3247b08df02acf0dd%7Cae1a772440414462a6dc538cb199707e%7C=
1%7C0%7C639232613954193166%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydW=
UsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C=
0%7C%7C%7C&amp;sdata=3DL1r%2FGmw3lU2HjcoJaHHYsGNwK0BQbAVjX6R6wThJMIk%3D&a=
mp;reserved=3D0</a>

On Sun, Aug 2, 2026 at 9:41=E2=80=AFPM Mohit Sethi via Datatracker
<a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:noreply@ietf.org">&lt;n=
oreply@ietf.org&gt;</a> wrote:
</pre>
      <blockquote type=3D"cite">
        <pre wrap=3D"" class=3D"moz-quote-pre">
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 Ex=
ternal
Pre-Shared Key (PSK) Usage in TLS") which provides PSK entropy requiremen=
ts and
the security properties that depend on them etc. For full disclosure, I a=
m a
co-author of RFC 9257. Additionally, section 3 should include a pointer t=
o
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" exte=
nsion
in IoT deployments.

Section 4 (Error Handling) doesn't reference RFC 7925 section 6. Also a b=
it
unclear what guidance is carried forward. What about the new alerts in TL=
S 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 oft=
en
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 "config=
ured
IP address and port... or a raw public key". This can lead to the misbind=
ing
attacks referenced in Appendix F.9 of RFC 9846. Maybe add a caution/refer=
ence.

Section 17.1.5 says that CA and subordinate CA can have finite validity p=
eriod
even when the end-entity certificate itself is valid until 99991231235959=
Z.
While I agree that this should be allowed, many (or most) CA implementati=
ons
don't allow this. See for example:
<a class=3D"moz-txt-link-freetext" href=3D"https://eur01.safelinks.protec=
tion.outlook.com/?url=3Dhttps%3A%2F%2Fdocs.aws.amazon.com%2Fprivateca%2Fl=
atest%2Fuserguide%2Fca-lifecycle.html&amp;data=3D05%7C02%7Cmohit.sethi%40=
aalto.fi%7Cda7462f4fc9541d3247b08df02acf0dd%7Cae1a772440414462a6dc538cb19=
9707e%7C1%7C0%7C639232613954222986%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG=
kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%=
3D%3D%7C0%7C%7C%7C&amp;sdata=3DMmow7m1MCgsE3fNk8ueUjH3VkN1tcQcEVKkH9FW8%2=
BiI%3D&amp;reserved=3D0">https://eur01.safelinks.protection.outlook.com/?=
url=3Dhttps%3A%2F%2Fdocs.aws.amazon.com%2Fprivateca%2Flatest%2Fuserguide%=
2Fca-lifecycle.html&amp;data=3D05%7C02%7Cmohit.sethi%40aalto.fi%7Cda7462f=
4fc9541d3247b08df02acf0dd%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C63=
9232613954222986%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw=
LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C=
&amp;sdata=3DMmow7m1MCgsE3fNk8ueUjH3VkN1tcQcEVKkH9FW8%2BiI%3D&amp;reserve=
d=3D0</a> (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" -&gt; this =
is
obvious as the peer needs to know the identity being authenticated. I wou=
ld
rather say "but the client identity/certificate is better protected as it=
 is
sent only after the server certificate is received and validated". This c=
ould
also be added in section 23 (Privacy Considerations).

Section 19 could perhaps reference RFC 9191. They both essentially contai=
n
similar guidance so not absolutely necessary. For full disclosure, I am a=

co-author of RFC 9191.

Typos etc.:
Section 17.4.4: digitialSignature -&gt; digitalSignature

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


--
Iot-directorate mailing list -- <a class=3D"moz-txt-link-abbreviated" hre=
f=3D"mailto:iot-directorate@ietf.org">iot-directorate@ietf.org</a>
To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre=
f=3D"mailto:iot-directorate-leave@ietf.org">iot-directorate-leave@ietf.or=
g</a>
</pre>
      </blockquote>
      <pre wrap=3D"" class=3D"moz-quote-pre">


--
Thomas

</pre>
    </blockquote>
  </body>
</html>

--------------wIhT3XPTQZidaslPkageUZFu--