Hi Daniel, thanks for the detailed review!
We have submitted a new draft version based on your feedback. A few remarks below: Von: Daniel Migault <[email protected]> Gesendet: Mittwoch, 13. August 2025 22:13 An: [email protected] Betreff: [Uta] draft-ietf-uta-tls13-iot-profile-14 (review) Hi, I went through the document draft-ietf-uta-tls13-iot-profile-14. The document is pleasant to read, but in my opinion it should have some stronger guidance. I provided some brief comments inline. Hope it helps. Happy to read future versions. Yours, Daniel 1. Introduction In the rapidly evolving Internet of Things (IoT) ecosystem, communication security is a critical requirement. The Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols have been foundational for ensuring encryption, integrity, and authenticity in communications. However, the constraints of a certain class of IoT devices render conventional, off-the-shelf TLS/ DTLS implementations suboptimal for many IoT use cases. This document addresses these limitations by specifying profiles of TLS 1.3 and DTLS 1.3, optimized for resource-constrained IoT devices. Note that IoT devices vary widely in terms of capabilities. While some are highly resource-constrained, others offer performance comparable to regular desktop computers but operate without end-user interfaces. For a detailed description of the different classes of IoT devices, please refer to [RFC7228] and [I-D.ietf-iotops-7228bis]. It is crucial for developers to thoroughly assess the limitations of their IoT devices and communication technologies to implement the most suitable optimizations. The profiles in this document aim to balance strong security with the hardware and software limitations of IoT devices. MGLT: I am finding the text below interesting, but I am not sure it is needed. I think ts purpose was to explain that TLS 1.3 and TLS 1.2 have significant differences. BUT I do not find these difference are impacting the profile. I have the impression we should probably give more details on what is needed by IoT that will justify some options in the profile. [Hannes] Describing the differences between 1.2 and 1.3 is important since several of the changes have surprising effects on the features. While those changes may be well known to those in the standardization community, many of the developers have not closely followed the standardization activities. TLS 1.3 has been re-designed and several previously defined extensions are not applicable to the new version of TLS/DTLS anymore. The following features changed with the transition from TLS 1.2 to 1.3: Tschofenig, et al. Expires 6 November 2025 [Page 3] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 * TLS 1.3 introduced the concept of post-handshake authentication messages, which partially replaced the need for the re-negotiation feature [RFC5746] available in earlier TLS versions. However, rekeying defined in Section 4.6.3 of [TLS13] does not provide forward secrecy MGT: right. In TLS 1.3 as far as I know seems to to only update the keys as its purpose is go over the sequence number. [Hannes] Yes, it does not offer any extra security features. and post-handshake authentication defined in Section 4.6.2 of [TLS13] only offers client-to-server authentication. The "Exported Authenticator" specification, see [RFC9261], recently added support for mutual, post-handshake authentication but requires the Certificate, CertificateVerify and the Finished messages to be exchanged by the application layer protocol, as it is exercised for HTTP/2 and HTTP/3 in [I-D.ietf-httpbis-secondary-server-certs]. MGLT: the text looks like application layer is involved, which sounds a bit strange to rely on above-TLS layers to compleet TLS. [Hannes] This may indeed look surprising but that is what the TLS working group came up with. * Rekeying of the application traffic secret does not lead to an update of the exporter secret (see Section 7.5 of [TLS13]) since the derived export secret is based on the exporter_master_secret and not on the application traffic secret. * Flight #4, which was used by EAP-TLS 1.2 [RFC5216], does not exist in TLS 1.3. As a consequence, EAP-TLS 1.3 [RFC9190] introduced a dummy message. * [RFC4279] introduced PSK-based authentication to TLS, a feature re-designed in TLS 1.3. The "PSK identity hint" defined in [RFC4279], which is used by the server to help the client in selecting which PSK identity to use, is, however, not available anymore in TLS 1.3. * Finally, ciphersuites were depreciated and the RSA-based key transport is not yet supported in TLS 1.3. As a consequence, only a Diffie-Hellman-based key exchange is available. MGLT: PSK does not require DH. [Hannes] I added a clarification. The profiles in this specification are designed to be adaptable to the broad spectrum of IoT applications, from low-power consumer devices to large-scale industrial deployments. It provides guidelines for implementing TLS/DTLS 1.3 in diverse networking contexts, including reliable, connection-oriented transport via TCP for TLS, and lightweight, connectionless communication via UDP for DTLS. In particular, DTLS is emphasized for scenarios where low- latency communication is paramount, such as multi-hop mesh networks and low-power wide-area networks, where the amount of data exchanged needs to be minimized. In conclusion, this document offers comprehensive guidance for deploying secure communication in resource-constrained IoT environments. It outlines best practices for configuring TLS/DTLS 1.3 to meet the unique needs of IoT devices, ensuring robust security without overwhelming their limited processing, memory, and power resources. The document plays a vital role in facilitating secure, efficient IoT deployments, supporting the broad adoption of secure communication standards. Tschofenig, et al. Expires 6 November 2025 [Page 4] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 2. Conventions and Terminology ... 3. Credential Types In accordance with the recommendations in [RFC7925], a compliant implementation MUST implement TLS_AES_128_CCM_8_SHA256. It SHOULD implement TLS_CHACHA20_POLY1305_SHA256. MGLT: I suspect it would be good to specify when TLS_CHACHA20_POLY1305_SHA256 does not need to be implemented. Given that my understanding is that we keep CCM because of hardware implementation, I am wondering why we do not consider CCM with larger signature. It would be good to explain why GCM is not even considered. Note also that it is a bit distant from credential type, so i am wondering if a dedicated section would not be appropriated. [Hannes] We deleted this entire paragraph. It is misplaced an incorrect. Pre-shared key based authentication is integrated into the main TLS/ DTLS 1.3 specification and has been harmonized with session resumption. A compliant implementation supporting authentication based on certificates and raw public keys MUST support digital signatures with ecdsa_secp256r1_sha256. A compliant implementation MUST support the key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519. MGLT: It is not clear to me if PSK, raw, X509 are mandatory or recommended. I think that should be clarified. [Hannes] We do not recommend one or the other. It is up to the IoT product designer to develop their threat model and to derive requirements. There may also be other constraints that influence the decision of the credential type. A plain PSK-based TLS/DTLS client or server MUST implement the following extensions: MGLT: It is my belief that plain PSK-based needs to be defined. In particular, does it means that it is only considering PSK or simply allowing PSK ? [Hannes] I added a clarification. Supported Version, Cookie and SNI does not seem related to PSK. Given the sentence a plain PSK based TLS implementation I woudl have expected PSK related extension. I think we need to explain why these extensions are there and specific to PSK. [Hannes] An implementation that supports PSK-based credentials still has to support these three extensions. Supported Version is required by the TLS 1.3 specification. Cookie is used for DDoS prevention and SNI is required for virtual hosting environments, which are very common today. * Supported Versions, * Cookie, * Server Name Indication (SNI), * Pre-Shared Key, * PSK Key Exchange Modes, and * Application-Layer Protocol Negotiation (ALPN). For use of external pre-shared keys [RFC9258] makes the following recommendation: Applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions. Where possible, the importer interface defined in [RFC9258] MUST be used for external PSKs. This ensures that external PSKs used in (D)TLS 1.3 are bound to a specific key derivation function (KDF) and hash function. MGLT: I think there are always bound to KDF and hash. What we want is that both hosts uses the same KDF and hash. Suppose that one PSK is used with a hash function that has become unsecured, I am wondering if the recommendation would be to keep on using it over an unsecured hash function as opposed a newly known secured hash function. Though it might be as secured as if we had always used the secured hash function, I am wondering it might still be better to use it this way. [Hannes] The purpose of RFC 9258 is generate different PSKs for different versions of TLS. This was the motivation for developing the RFC. Of course, if you do not mix different versions of the TLS & DTLS protocol in your deployment then this issue goes away. I think what you are saying is that there are other ways to accomplish that goal but this is outside the scope of this draft. Tschofenig, et al. Expires 6 November 2025 [Page 5] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 The SNI extension is discussed in this document and the justification for implementing and using the ALPN extension can be found in [RFC9325]. For TLS/DTLS clients and servers implementing raw public keys and/or certificates the guidance for mandatory-to-implement extensions described in Section 9.2 of [RFC8446] MUST be followed. 4. Error Handling ... 5. Session Resumption ... 6. Compression ... 7. Forward Secrecy ... 8. Authentication and Integrity-only Cipher Suites For a few, very specific Industrial IoT use cases [RFC9150] defines two cipher suites that provide data authenticity, but not data confidentiality. Please review the security and privacy considerations about their use detailed in Section 9 of [RFC9150]. MGLT: I think this should be turned into a recommendation [Hannes] We intentionally did not want to turn this into a recommendation because it is not clear what exactly we should be recommending. Instead, we make the reader aware of it. 9. Keep-Alive The discussion in Section 10 of [RFC7925] is applicable. 10. Timers and ACKs ... 11. Random Number Generation ... 12. Server Name Indication This specification mandates the implementation of the Server Name Indication (SNI) extension. Where privacy requirements require it, the ECH (Encrypted Client Hello) extension [I-D.ietf-tls-esni] prevents an on-path attacker to determine the domain name the client is trying to connect to. Since the Encrypted Client Hello extension requires use of Hybrid Public Key Encryption (HPKE) [RFC9180] and additional protocols require further protocol exchanges and cryptographic operations, there is a certain overhead associated with this privacy feature. Note that in industrial IoT deployments the use of ECH may not be an option because network administrators inspect DNS traffic generated by IoT devices in order to detect malicious behaviour. MGLT: "May not be an option" can have different different interpretation (at least to me): not allowed or mandatory. [Hannes] I added clarifying text. Besides, to avoid leaking DNS lookups from network inspection altogether further protocols are needed, including DoH [RFC8484] and DPRIVE [RFC7858] [RFC8094]. For use of such techniques in managed networks, the reader is advised to keep up to date with the protocols defined by the Adaptive DNS Discovery (add) working group [ADD]. 13. Maximum Fragment Length Negotiation ... 14. Crypto Agility The recommendations in Section 19 of [RFC7925] are applicable. 15. Key Length Recommendations The recommendations in Section 20 of [RFC7925] are applicable. Tschofenig, et al. Expires 6 November 2025 [Page 8] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 16. 0-RTT Data Appendix E.5 of [TLS13] establishes that: Application protocols MUST NOT use 0-RTT data without a profile that defines its use. That profile needs to identify which messages or interactions are safe to use with 0-RTT and how to handle the situation when the server rejects 0-RTT and falls back to 1-RTT. At the time of writing, no such profile has been defined for CoAP [CoAP]. Therefore, 0-RTT MUST NOT be used by CoAP applications. MGLT: I understand such profile word be needed on a PER APPLICATION basis. I do not envision a profile that would match CoAP as a whole. [Hannes] We left this statement as is because this is inline with what the TLS RFC says. Here is a link to the PR, which we tried to come up with: https://github.com/thomas-fossati/draft-tls13-iot/pull/89 17. Certificate Profile This section contains updates and clarifications to the certificate profile defined in [RFC7925]. The content of Table 1 of [RFC7925] has been split by certificate "type" in order to clarify exactly what requirements and recommendations apply to which entity in the PKI hierarchy. The content is also better aligned with the IEEE 802.1AR [_8021AR] specification, which introduces the terms Initial Device Identifier (IDevID) and Locally Significant Device Identifiers (LDevIDs). IDevIDs and LDevIDs are Device Identifiers (DevIDs). A DevID consists of MGLT: The sentence may look a bit strange. """IDevIDs and LDevIDs are Device Identifiers (DevIDs).""" I could probably infer that one is initial and the other is local ;-) I would maybe suggest simply saying both Device Identifiers consists of: * a private key, * a certificate (containing the public key and the identifier certified by the certificate's issuer), and * a certificate chain up to a trust anchor. The trust anchor is usually the root certificate). MGLT: I was expecting some characteristics specific to DevIDs, I do not see anything that differ from a certificate binding an identity to a private key. The section on DevIDs does not seem necessary at that point. [Hannes] I have changed the wording of this section a bit. Note that the trust anchor does not need to be transmitted in the TLS Certificate message sent by the server. The client MUST NOT use any trust anchor provided in the Certificate message, because the trust anchor is provisioned via out-of-band means. Therefore, transmitting the trust anchor in the Certificate message is a waste of bandwidth. If the trust anchor is not the root CA certificate, the server may be unaware of which trust anchor the client has. In such cases, the client can use the Trusted CA Indication, defined in [RFC6066], to indicate which trust anchors it possesses. MGLT: I believe the text above is confusing and should simply RECOMMEND not to include the root Certificate in the Certificate and ignore rootCertificates. I tend to say that such recommendation is related to TLS and not certificate, so I would move it to the TLS section. [Hannes] I also changed this text. Tschofenig, et al. Expires 6 November 2025 [Page 9] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 The IDevID is typically provisioned by a manufacturer and signed by the manufacturer CA. It is then used to obtain operational certificates, the LDevIDs, from the operator or owner of the device. Some protocols also introduce an additional hierarchy with application instance certificates, which are obtained for use with specific applications. IDevIDs are primarily used with device onboarding or bootstrapping protocols, such as the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol [RFC8995] or by LwM2M Bootstrap [LwM2M]. Hence, the use of IDevIDs is limited in purpose even though they have a long lifetime, or do not expire at all. While some bootstrapping protocols use TLS (and therefore make use of the IDevID as part of client authentication) there are other bootstrapping protocols that do not use TLS/DTLS for client authentication, such as FIDO Device Onboarding (FDO) [FDO]. In many cases, a profile for the certificate content is provided by those specifications. For these reasons, this specification focuses on the description of LDevIDs. While the IEEE 802.1AR terminology is utilized in this document, this specification does not claim conformance to IEEE 802.1AR since such a compliance statement goes beyond the use of the terminology and the certificate content and would include the use of management protocols, fulfillment of certain hardware security requirements, and interfaces to access these hardware security modules. Placing these requirements on network equipment like routers may be appropriate but designers of constrained IoT devices have opted for different protocols and hardware security choices. MGLT: While the DevID description is interesting, the section needs to highlight what difference it makes to certificates. [Hannes] IEEE 802.1AR has gotten popular in the IoT context and to a large extend it is really only about the terminology. Re-using the terminology will help readers to better understand the text. 17.1. All Certificates To avoid repetition, this section outlines requirements on X.509 certificates applicable to all PKI entities. 17.1.1. Version Certificates MUST be of type X.509 v3. Note that TLS 1.3 allows to convey payloads other than X.509 certificates in the Certificate message. The description in this section only focuses on X.509 v3 certificates and leaves the description of other formats to other sections or even other specifications. Tschofenig, et al. Expires 6 November 2025 [Page 10] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 17.1.2. Serial Number ... 17.1.3. Signature ... 17.1.4. Issuer ... 17.1.5. Validity In IoT deployment scenarios it is often expected that the IDevIDs have no maximum validity period. For this purpose the use of a special value for the notAfter date field, the GeneralizedTime value of 99991231235959Z, is utilized. MGLT: we should say where such value comes from. [Hannes] Added a reference. If this is done, then the CA certificates and the certificates of subordinate CAs cannot have a maximum validity period either. Hence, it requires careful consideration whether it is appropriate to issue IDevID certificates with no maximum validity period. MGLT: I think the text needs to be clarified. The first sentence says that IoT are expected to have no maximum validity period. The consequence of it is that CA, subCA also have no maximum validity. I suggest to mention what needs to be considered carefully here. Then I suggest to simply how no maximum validity period is enforced - i.e. 99991231235959Z. [Hannes] Added text here too. LDevID certificates are, however, issued by the operator or owner, and may be renewed at a regular interval using protocols, such as Enrollment over Secure Transport (EST) [RFC7030] or the Certificate Management Protocol (CMP) [RFC9483]. It is therefore RECOMMENDED to limit the lifetime of these LDevID certificates using the notBefore and notAfter fields, as described in Section 4.1.2.5 of [RFC5280]. Values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds even where the number of seconds is zero. MGLT: I think it would be good to mention different CA can be involved and CMP can be used to switch from the CA of the IDevID to the one of the LDevID. [Hannes] While this is true and in most cases will be done I think it should be left to the referenced document to get into those details. Tschofenig, et al. Expires 6 November 2025 [Page 11] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 Note that the validity period is defined as the period of time from notBefore through notAfter, inclusive. This means that a hypothetical certificate with a notBefore date of 9 June 2021 at 03:42:01 and a notAfter date of 7 September 2021 at 03:42:01 becomes valid at the beginning of the :01 second, and only becomes invalid at the :02 second, a period that is 90 days plus 1 second. So for a 90-day, notAfter must actually be 03:42:00. For devices without a reliable source of time we advise the use of a device management solution, which typically includes a certificate management protocol, to manage the lifetime of all the certificates used by the device. While this approach does not utilize certificates to its widest extent, it is a solution that extends the capabilities offered by a raw public key approach. 17.1.6. Subject Public Key Info ... 17.1.7. Certificate Revocation Checks The guidance in Section 4.4.3 of [RFC7925] still holds: for certificate revocation, neither the Online Certificate Status Protocol (OCSP) nor Certificate Revocation Lists (CRLs) are used by constrained IoT devices. Since the publication of RFC 7925 the need for firmware update mechanisms has been reinforced and the work on standardizing a secure and interoperable firmware update mechanism has made substantial progress, see [RFC9019]. RFC 7925 recommends to use a software / firmware update mechanism to provision devices with new trust anchors. This approach only addresses the distribution of trust anchors and not end entity certificates or certificates of subordinate CAs. MGLT: The paragraph above seems more related to Trust Anchor (RootCA) management than actually certificate revocation. [Hannes] Moved this paragraph. Tschofenig, et al. Expires 6 November 2025 [Page 12] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 The use of device management protocols for IoT devices, which often include an onboarding or bootstrapping mechanism, has also seen considerable uptake in deployed devices. These protocols, some of which are standardized, MGLT: It is my belief that examples would be useful here. [Hannes] We did not want to get into examples here because those age quickly. What is popular in deployments today is gone tomorrow. allow for the distribution and updating of certificates on demand. This enables a deployment model where IoT device utilize end entity certificates with shorter lifetime making certificate revocation protocols, like OCSP and CRLs, less relevant. Whenever certificates are updated the TLS stack needs to be informed since the communication endpoints need to be aware of the new certificates. This is particularly important when long-lived TLS connections are used. In such a case, the post-handshake authentication exchange is triggered when the application requires it. TLS 1.3 provides client-to-server post-handshake authentication only. Mutual authentication via post-handshake messages is available by the use of the "Exported Authenticator" [RFC9261] but requires the application layer protocol to carry the payloads. MGLT: This seems horribly complex, it would be good to know whether this is recommended or not to use such mechanism. I believe it really depends on the trust model since there is not a mandatory need to re-authenticate regularly once the session has been authenticated once. Authentication is performed at a given time, there is no commitment it remains unchanged during the entire TLS session. I think the only reason we need to authenticate id when the key is rogue and we have later realized the current TLS session has been authenticated with that rogue key. In any other cases, it seems fine, security relies on the TSL session key not the authentication. I see authentication as the main source of consumption, so I would like to understand the effective gain instead of doing a reconnection. I am wondering why we do not simply request to reconnect every X period of time to keep things light. Note that authenticators are mostly done to handle different identities [Hannes] If you want the functionality in your deployment then you have to use this mechanism. The exported authenticator functionality is just what it is. Hence, instead of performing certificate revocation checks on the IoT device itself this specification recommends MGLT: Maybe a normative language would be more appropriated: RECOMMENDS [Hannes] Done. to delegate this task to the IoT device operator and to take the necessary action to allow IoT devices to remain operational. The CRL distribution points extension has been defined in RFC 5280 to identify how CRL information is obtained. The authority information access extension indicates how to access information like the online certificate status service (OCSP). Both extensions SHOULD NOT be set. If set, they MUST NOT be marked critical. MGLT:The text above says everything we need to know regarding OCSP and CRL. It should maybe be moved to the beginning. Since there is no revocation, we use shorter life time certificate and update are handled in various ways - software updates - certificate management. I think we need a recommendations on what method is recommended here and why. The management of TA seems to be the purpose of a dedicated section. The necessity to re authenticate regularly as well. This latest point need to detail the underlying security / trust model. [Hannes] Moved the text about TA management into a separate section. MGLT: I would like a section on Subject SAN. [Hannes] What would you write? 17.2. Root CA Certificate This section outlines the requirements for root CA certificates. 17.2.1. Subject [RFC5280] mandates that Root CA certificates MUST have a non-empty subject field. The subject field MUST contain the commonName, the organizationName, and the countryName attribute and MAY contain an organizationalUnitName attribute. MGLT: is-it Subject instead of subject ? [Hannes] I think it is „subject“. 17.2.2. Authority Key Identifier Section 4.2.1.1 of [RFC5280] defines the Authority Key Identifier as follows: "The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign a certificate. This extension is used where an issuer has multiple signing keys." Tschofenig, et al. Expires 6 November 2025 [Page 13] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 The Authority Key Identifier extension MAY be omitted. If it is set, it MUST NOT be marked critical, and MUST contain the subjectKeyIdentifier of this certificate. [Editor's Note: Do we need to set the Authority Key Identifier in the CA certificate?] MGLT: My question is how the IoT would handle a change of key from the CA. The configuration of the TA is part of the discussion, but we expect clear guidance. [Hannes] Deleted this point. 17.2.3. Subject Key Identifier ... 17.2.4. Key Usage [RFC5280] defines the key usage field as follows: "The key usage extension defines the purpose (e.g., encipherment, signature, certificate signing) of the key contained in the certificate." The Key Usage extension MAY be set. If it is set, it MUST be marked critical and the keyCertSign or cRLSign purposes MUST be set. Additional key usages MAY be set depending on the intended usage of the public key. [RFC5280] defines the extended key usage as follows: "This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension." MGLT: It is my beehive that we should avoid repeating the text. I would rather just indicate where in the main specification this is specified as well as to what extend this differs from the main specification. [Hannes] There is no harm in repeating the text here and it helps the reader. This extendedKeyUsage extension MUST NOT be set in CA certificates. 17.2.5. Basic Constraints Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 * "The pathLenConstraint field is meaningful only if the cA boolean is asserted and the key usage extension, if present, asserts the keyCertSign bit. In this case, it gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path." * "A pathLenConstraint of zero indicates that no non-self-issued intermediate CA certificates may follow in a valid certification path." * "Where pathLenConstraint does not appear, no limit is imposed." * "Conforming CAs MUST include this extension in all CA certificates that contain public keys used to validate digital signatures on certificates and MUST mark the extension as critical in such certificates." The Basic Constraints extension MUST be set, MUST be marked critical, the cA flag MUST be set to true and the pathLenConstraint MUST be omitted. [Editor's Note: Should we soften the requirement to: "The pathLenConstraint field SHOULD NOT be present."] MGLT: We need to understand the rational for having it or not. The rational needs to balance the number of bytes versus the IoT usage and the potential security impacts. [Hannes] Deleted this statement. 17.3. Subordinate CA Certificate ... 17.3.1. Subject ... 17.3.2. Authority Key Identifier ... 17.3.3. Subject Key Identifier The Subject Key Identifier extension MUST be set, MUST NOT be marked critical, and MUST contain the key identifier of the public key contained in the subject public key info field. Tschofenig, et al. Expires 6 November 2025 [Page 15] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 17.3.4. Key Usage .. 17.3.5. Basic Constraints ... 17.3.6. CRL Distribution Point ... 17.3.7. Authority Information Access ... 17.4. End Entity Certificate This section outlines the requirements for end entity certificates. 17.4.1. Subject This section describes the use of end entity certificate primarily for (D)TLS clients running on IoT devices. Operating (D)TLS servers on IoT devices is possible but less common. [RFC9525], Section 2 mandates that the subject field not be used to identify a service. However, certain IoT applications (for example, [I-D.ietf-anima-constrained-voucher], [_8021AR]) use the subject field to encode the device serial number. The requirement in Section 4.4.2 of [RFC7925] to only use EUI-64 for end entity certificates as a subject field is lifted. Tschofenig, et al. Expires 6 November 2025 [Page 16] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 Two fields are typically used to encode a device identifier, namely the Subject and the subjectAltName fields. Protocol specifications tend to offer recommendations about what identifiers to use and the deployment situation is fragmented. The subject field MAY include a unique device serial number. If the serial number is included, it MUST be encoded in the X520SerialNumber attribute. e.g., [RFC8995] use requires a serial number in IDevID certificates. [RFC5280] defines: "The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate." The subject alternative name extension MAY be set. If it is set, it MUST NOT be marked critical, except when the subject DN contains an empty sequence. If the EUI-64 format is used to identify the subject of an end entity certificate, it MUST be encoded as a Subject DN using the X520SerialNumber attribute. The contents of the field is a string of the form HH-HH-HH-HH-HH-HH-HH-HH where 'H' is one of the symbols '0'-'9' or 'A'-'F'. Per [RFC9525] domain names MUST NOT be encoded in the subject commonName. Instead they MUST be encoded in a subjectAltName of type DNS-ID. Domain names MUST NOT contain wildcard (*) characters. The subjectAltName MUST NOT contain multiple names. Note: The IEEE 802.1AR recommends to encode information about a Trusted Platform Module (TPM), if present, in the HardwareModuleName. This specification does not follow this recommendation. MGLT: is HardwareModuleName defined in an RFC ? If so, we may add a reference here. [Hannes] Added a reference here. Where IoT devices are accepting (D)TLS connections, i.e., they are acting as a server, it is unlikely that there will be a useful name that can go into the SNI. In general, the use of SNI for the purpose of virtual hosting on constrained IoT devices is rare. The IoT device cannot depend on a client providing a correct SNI, and so it MUST ignore the extension. This implies that IoT devices cannot do name-based virtual hosting of TLS connections. In the unlikely event that an IoT device has multiple servers responding with different server certificate, then the server SHOULD use different IP addresses or port numbers. MGLT: It is my believe that this section should come out with some recommendations on how to name a IoT client / server. EUI-64 and FQDN are listed, but I am wondering what about UUID or any other scheme. [Hannes] In the past we made the effort to talk about the different naming schemes and it was a failure. So, we are not going there again. Tschofenig, et al. Expires 6 November 2025 [Page 17] Internet-Draft TLS/DTLS 1.3 IoT Profiles May 2025 17.4.2. Authority Key Identifier ... 17.4.3. Subject Key Identifier ... 17.4.4. Key Usage The key usage extension MUST be set and MUST be marked as critical. For signature verification keys the digitialSignature key usage purpose MUST be specified. Other key usages are set according to the intended usage of the key. If enrollment of new certificates uses server-side key generation, encrypted delivery of the private key is required. In such cases the key usage keyEncipherment or keyAgreement MUST be set because the encrypted delivery of the newly generated key involves encryption or agreement of a symmetric key. On-device key generation is, however, the preferred approach. MGLT: I am finding this a bit orthogonal to the purpose of the draft which is certificates for TLS. These seem to me more part of certificate management. [Hannes] It is certainly at the border of TLS but has implication to the use of TLS. In IDevID certificates, the extendedKeyUsage SHOULD NOT be present, as it reduces the utility of the IDevID. MGLT: If the justification for not having KE is that the key is used for multiple purposes, we need to explicitel explain which operations are expected by the IDevID that doe snot fit a KE. In addition multiple KE may be added. [Hannes] Clarified the text. This comes from the IEEE 802.1AR spec. In locally assigned LDevID certificates, the extendedKeyUsage, if present, MUST contain at least one of id-kp-serverAuth or id-kp-clientAuth in order to be useable with TLS. 18. Certificate Overhead ... 19. Ciphersuites MGLT: In general I believe that the ciphersuiets considerations that have been made previously should be placed in this section and only this section. [Hannes] Agree with your observation. We deleted the first paragraph about ciphersuites from the credential type section. According to Section 4.5.3 of [DTLS13], the use of AES-CCM with 8-octet authentication tags (CCM_8) is considered unsuitable for general use with DTLS. This is because it has low integrity limits (i.e., high sensitivity to forgeries) which makes endpoints that negotiate ciphersuites based on such AEAD vulnerable to a trivial DoS attack. See also Sections 5.3 and 5.4 of [I-D.irtf-cfrg-aead-limits] for further discussion on this topic, as well as references to the analysis supporting these conclusions. Specifically, [DTLS13] warns that: > TLS_AES_128_CCM_8_SHA256 MUST NOT be used in DTLS without additional > safeguards against forgery. Implementations MUST set usage limits for > AEAD_AES_128_CCM_8 based on an understanding of any additional forgery > protections that are used. Since all the ciphersuites required by [RFC7925] and [CoAP] rely on CCM_8, there is no alternate ciphersuite available for applications that aim to eliminate the security and availability threats related to CCM_8 while retaining interoperability with the larger ecosystem. In order to ameliorate the situation, it is RECOMMENDED that implementations support the following two ciphersuites for TLS 1.3: * TLS_AES_128_GCM_SHA256 * TLS_AES_128_CCM and offer them as their first choice. These ciphersuites provide confidentiality and integrity limits that are considered acceptable in the most general settings. For the details on the exact bounds of both ciphersuites see Section 4.5.3 of [DTLS13]. Note that the GCM- based ciphersuite offers superior interoperability with cloud services at the cost of a slight increase in the wire and peak RAM footprints. When the GCM-based ciphersuite is used with TLS 1.2, the recommendations in Section 7.2.1 of [RFC9325] related to deterministic nonce generation apply. In addition, the integrity limits on key usage detailed in Section 4.4 of [RFC9325] also apply. Table 1 summarizes the recommendations regarding ciphersuites: Ciao Hannes -- Daniel Migault Ericsson
_______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
