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]
