Hi Roman,
Thank you very much for your detailed review!
We believe that we have addressed your comments in commit [1], which has
been folded into version -24 alongside the rest of the IESG-review
processing.
In particular, re: the PQC topic. Given the delicate and unstable
nature of the subject :sweat:, we have decided to delegate the bulk of
the considerations to draft-ietf-uta-pqc-app, which is a work in
progress of Tiru and Hannes.
The new text is the second paragraph of Section 20 [1] and it's framed
*very* informatively:
Guidance for using post-quantum cryptography with application
protocols, including TLS, is provided by [I-D.ietf-uta-pqc-app].
That document is the primary source of PQC deployment recommendations
for applications and constrained environments. It discusses
algorithm selection, migration planning, and the operational impact
of larger key shares, public keys, signatures, and certificates.
That merges quite nicely into the 3rd para which further elaborates
while completely refraining from setting out any requirements.
Please let us know if this is suitable or if you have any further comments.
cheers!
[1]
https://github.com/thomas-fossati/draft-tls13-iot/pull/223/changes/4aa8ae1
[2]
https://author-tools.ietf.org/iddiff?url2=draft-ietf-uta-tls13-iot-profile-24
On 31.07.2026 23:33, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-uta-tls13-iot-profile-23: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-tls13-iot-profile/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Russ Housley for the GENART review.
** Meta-data and Section 17. Why is this document updating a profile (RFC7925)
for protocols that have already been obsoleted? Why doesn’t this document
obsolete RFC7925?
RFC 9147 (DTLS 1.3) obsoleted RFC6347 (DTLS 1.2)
RFC 8446/9846 (TLS 1.3) obsoleted RFC 5246 (TLS 1.2)
What does it mean to update a profile for an obsoleted protocol?
** Idnits reports:
== Unused Reference: 'RFC7452' is defined on line 1684, but no explicit
reference was found in the text
** Section 3.
TLS/DTLS 1.3 implementations conforming to this profile MUST follow
the mandatory-to-implement extension requirements in Section 9.2 of
[RFC9846]. This section summarizes those requirements and the
additional extension requirements established by this profile. The
table does not replace the normative requirements in the referenced
sections.
…
<all the contents of Table 1>
Why is this text needed? Without it, the default guidance in [RFC9846] would
still apply to make these extensions MTI. All the text appears to say here is
affirming that the mandate in RFC9846 continues to apply.
** Section 4. It isn’t clear what IOT profiling is being done with this text.
The “standard” RFC9846 behavior of TLS does not appear to be enhanced. Can
this text be removed?
** Section 5. Same comment as for Section 4. The text appears to be restating
RFC9846 mechanisms without profiling. Can this text be removed?
** Section 6. Same comment as for Section 4 and 5. Can this text be removed?
** Section 11
TLS 1.3 requires implementations to support the Server Name
Indication (SNI) extension when used with applications capable of
using it (Section 9.2 of [RFC9846]). This profile does not change
that requirement.
How could a profile “change that requirement” if the base spec requires support?
** Section 16. I didn’t understand the purpose of this section. If this
section didn’t exist, the guidance from Appendix F.5 of RFC9846 will already
mandate that “Application protocols MUST NOT use 0-RTT data without a profile”.
However, this document seems to repeat this restriction by saying “For any
application protocol, 0-RTT MUST NOT be used unless a protocol-specific profile
exists.”
Further, this text, “At the time of writing, no such profile has been defined
for CoAP [CoAP]. Therefore, 0-RTT MUST NOT be used by CoAP applications.”,
again restates what would have been true whether it was written or not.
Per “No specific recommendations are given for non-IETF IoT protocols such as
MQTT (Message Queuing Telemetry Transport)”, how would this document even
specify recommendation for non-IETF profiles?
** Section 17.1.3.
The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758].
What is “or stronger” in this context is it ecdsa-with-SHA384 or
ecdsa-with-SHA512, or suggesting an entire different signature algorithm family?
** Section 18. How is this text profiling TLS/DTLS? What is their
relationship to IoT?
** Section 19. The normative guidance for the TLS/DTLS profile is not clear in
this section.
** Section 21. How is this text profiling TLS/DTLS? What is their
relationship to IoT?
** Section 22.
22. Post-Quantum Cryptography (PQC) Considerations
This section is informational and provides deployment guidance only;
it does not add normative requirements to this profile.
I don’t understand the purpose of this text. There are many parts of this
document which do not place normative requirements on the profile.
** Section 24.
Deployments considering such cipher suites, such as
defined in [RFC9150], need application-specific analysis outside the
scope of this document.
This is restating guidance that is true for the entire TLS/DTLS ecosystem.
_______________________________________________
Uta mailing list -- [email protected]
To unsubscribe send an email to [email protected]
