IETF Last Call Review of draft-ietf-uta-tls13-iot-profile-21
review-ietf-uta-tls13-iot-profile-21-genart-lc-housley-2026-05-26-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-uta-tls13-iot-profile-21
Reviewer: Russ Housley
Review Date: 2026-05-26
IETF LC End Date: 2026-06-09
IESG Telechat date: unknown


Summary: Not Ready


Major Concerns:

TLS 1.3 only uses certificates with signature public keys.  TLS 1.2
supports other types of public keys, such as Diffie-Hellman public
keys.  If the statements about updating RFC 7925 are intended to
prohibit the use of such certificate with TLS 1.2, please be explicit
about doing so.

Section 3 does not discuss the use of external PSKs and certificates as
defined in draft-ietf-tls-8773bis, which is in the RFC Editor's queue.
None of the cipher suites in this document are post-quantum safe, and
this does off a way to achieve that goal at the expense of external PSK
distribution.  This could be discussed in Section 22 of this document.

Section 12 should offer guidance about when support for ECH is needed.
I do not think that "Where privacy requirements necessitate it" is
sufficient.  Perhaps the whole ECH discussion could appear in Section 23
of this document.  If not, the two sections should be cross referenced.

Section 14 is not sufficient.  Section 19 of [RFC7925] recommends
AES-CCM, but this document recommends AES-GCM.

Section 15 is not sufficient.  Section 20 of [RFC7925] says that 112-bit
security is acceptable, which is equivalent to Triple-DES security.
NIST phased-out period for Triple-DES on 31 December 2023.


Minor Concerns:

Section 17 uses the term "PKI hierarchy".  While many PKIs are hierarchical,
some are meshes.  RFC 5280 accommodates both.  Thus. this should be reworded
to talk about the certificates that make up the certification path from the
trust encho to the end entity certificate.

I expected Section 17 to require alignment to RFC 5280.  Many of the
requirements in this Section are restatement of things in RFC 5280, not
additional requirements.

Section 17.1.2: CAs often combine a counter and a random value,

Section 17.2.4: Please separate the discussion ot key usage and extended key
usage into separate sections.

Section 17.4.1: Why prohibit the use of MACAddress otherName as specified
in draft-ietf-lamps-macaddress-on, which is in the RFC Editor's queue.

Section 17.3.4: Please separate the discussion ot key usage and extended key
usage into separate sections.


Nits:

Section 17: s/IEEE 802.1AR deployments.  It is used/
             /[IEEE-802.1AR] deployments.  Terms from IEEE 802.1AR are used/

Section 17.1.5: s/notAfter must actually be 03:42:00/
                 /the time portion of notAfter is 03:42:00/

Section 17.1.6: s/CA certificates and certificates of subordinate CAs/
                 /CA certificates/