Hi all,
Daniel, thank you very much for careful reviewing the draft.
Authors, can you please comment on the remaining remarks from Daniel?
The draft is about to be sent to the IESG waiting for your feedback.
Regards,
Valery.
From: Daniel Migault <[email protected]>
Sent: Friday, November 7, 2025 8:30 PM
To: Renzo Navas <[email protected]>
Cc: [email protected]; Tschofenig, Hannes <[email protected]>
Subject: [Uta] Re: New version of "TLS/DTLS 1.3 Profiles for the Internet of
Things"
Hi,
I have several remarks regarding the current draft. These are primarily minor
issues, so you may choose to address them or disregard them and proceed with
the document.
One observation that I believe holds greater significance is that, in my view,
the ongoing validation of the certificate throughout an extended TLS session is
not a function of TLS itself, but rather a requirement of the application. I
think the text should be clearer on this point.
Additionally, I am curious about the necessity of presenting the complete chain
in a TLS exchange. Generally, I am questioning whether it would be feasible to
provide only the End Entity (EE) certificate and utilize Authority Information
Access (AIA) to obtain the complete chain, for instance.
Other comments:
TLS/DTLS 1.3 Profiles for the Internet of Things
draft-ietf-uta-tls13-iot-profile-17
Abstract
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for
Internet of Things (IoT) devices with resource constraints. This
mglt: I am not sure we need to mention TLS 1.2
document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles
for IoT devices. Additionally, it updates RFC 7925 with respect to
the X.509 certificate profile and ciphersuite requirements.
1. Introduction
...
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:
* 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, the
rekeying mechanism defined in Section 4.6.3 of [TLS13] does not
provide post-compromise security (see Appendix E.1.5 of [TLS13]).
Furthermore, post-handshake authentication defined in
Section 4.6.2 of [TLS13] only offers client-to-server
authentication.
mglt: isn't it client authentication ?
The "Exported Authenticator" specification, see
[RFC9261], added support for mutual post-handshake authentication,
but this requires the Certificate, CertificateVerify and the
Finished messages to be conveyed by the application layer
protocol, as it is exercised for HTTP/2 and HTTP/3 in
[I-D.ietf-httpbis-secondary-server-certs]. Therefore, the
application layer protocol must be enhanced whenever this feature
is required.
* 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.
mglt: I think dummy is part of banned words.
* [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 supported in TLS 1.3. As a consequence, only a
Diffie-Hellman-based key exchange is available for non-PSK-based
authentication. (For PSK-based authentication the use of Diffie-
Hellman is optional.)
mglt: I suspect non-PSK-based means certificate based. It is my belief the
latest is clearer.
...
2. Conventions and Terminology
...
3. Credential Types
TLS/DTLS allow different credential types to be used. These include
X.509 certificates and raw public keys, pre-shared keys (PSKs), and
passwords. The extensions used in TLS/DTLS differ dependencing on
the credential types supported.
mglt: dependencing
TLS/DTLS 1.3 supports PSK-based authentication, wherein PSKs can be
established via session tickets from prior connections or via some
external, out-of-band mechanism. To distinguish the two modes, the
former is called resumption PSK and the latter external PSK. For
performance reasons the support for resumption PSKs is often found in
implementations that use X.509 certificates for authentication.
mglt: what about the external PSK ?
A "plain" PSK-based TLS/DTLS client or server, which only implements
support for external PSKs as its long-term credential, MUST implement
the following extensions:
* Supported Versions,
* Cookie,
* Server Name Indication (SNI),
* Pre-Shared Key,
* PSK Key Exchange Modes, and
* Application-Layer Protocol Negotiation (ALPN).
mglt: my reading of teh text was that the extensions MUST be supported for the
purpose of supporting clients and server supporting external PSK
authentication. I actually believe that these options are also carried when
ECDHE or session resumption is handled. I THINK we should explicitly mention
these options can be carried by other clients.
For use of external pre-shared keys [RFC9258] makes the following
recommendation:
Tschofenig, et al. Expires 21 April 2026 [Page 5]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
Applications SHOULD provision separate PSKs for (D)TLS 1.3 and
prior versions.
mglt: itemizing for a single recommendation may not be necessary. We shoudl
probably stick to external PSK.
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.
The SNI extension is discussed in this document and the justification
for implementing and using the ALPN extension can be found in
[RFC9325].
mglt: the paragraph does not add uch details. I believe it should simply say
ALPN is discuses in section XXX.
An 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: I am surprised to find client ECDHE after we described PSK
authentication. I think what is missing in the begining is the mention that IoT
considers certificate and external PSK authentication. This would clearly state
which modes are considered. For now PSK + ECDHE combined is not considered. It
will also prepare the reader to get both types of recommendations.
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.
mglt: is self signed cert considered as raw key ?
Entities deploying IoT devices may select credential types based on
security characteristics, operational requirements, cost, and other
factors. Consequently, this specification does not prescribe a
single credential type but provides guidance on considerations
relevant to the use of particular types.
4. Error Handling
...
5. Session Resumption
TLS 1.3 has built-in support for session resumption by utilizing PSK-
based credentials established in an earlier exchange.
mglt: The section looks very strange. I suspect the reason is that you follow
the TLS 1.2 structure. Please make it explicit.
Tschofenig, et al. Expires 21 April 2026 [Page 6]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
6. Compression
...
With regards to the handshake itself, various strategies have been
applied to reduce the size of the exchanged payloads. TLS and DTLS
1.3 use less overhead, depending on the type of key confirmations,
when compared to previous versions of the protocol. Additionally,
the work on Compact TLS (cTLS) [I-D.ietf-tls-ctls] has taken
compression of the handshake a step further by utilizing out-of-band
knowledge between the communication parties to reduce the amount of
data to be transmitted at each individual handshake, among applying
other techniques.
mglt: In it current form, it is suprising to have a section to mention TLS 1.3
does not support the property.
7. Forward Secrecy
RFC 8446 has removed Static RSA and Static Diffie-Hellman cipher
suites, therefore all public-key-based key exchange mechanisms
available in TLS 1.3 provide forward secrecy.
Pre-shared keys (PSKs) can be used with (EC)DHE key exchange to
provide forward secrecy or can be used alone, at the cost of losing
forward secrecy for the application data.
mglt: this section is a bit strange in the sense that there is no
recommendation on whether ECHDE shoudl be used with PSK.
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 document should completely differ to 9150 beyond the section
9 - especially as I am expecting a very few number of tls libraries to support
it - but I might be wrong.
9. Keep-Alive
The discussion in Section 10 of [RFC7925] is applicable.
10. Timers and ACKs
Compared to DTLS 1.2 timeout-based whole flight retransmission, DTLS
1.3 ACKs sensibly decrease the risk of congestion collapse which was
the basis for the very conservative recommendations given in
Section 11 of [RFC7925].
In general, the recommendations in Section 7.3 of [DTLS13] regarding
ACKs apply. In particular, "(w)hen DTLS 1.3 is used in deployments
mglt: Do you mean applies for TLS 1.3 AND DTLS 1.3. If so, I beleiev this
should be made explicit.
with lossy networks, such as low-power, long-range radio networks as
...
Due to the vast range of network technologies used in IoT
deployments, from wired LAN to GSM-SMS, it's not possible to provide
a universal recommendation for an initial timeout. Therefore, it is
RECOMMENDED that DTLS 1.3 implementations allow developers to
explicitly set the initial timer value. Developers SHOULD set the
initial timeout to be twice the expected round-trip time (RTT), but
no less than 1000ms. For specific application/network combinations,
mglt: it would be good to explain where that 1000 ms comes from.
a sub-second initial timeout MAY be set. In cases where no RTT
estimates are available, a 1000ms initial timeout is suitable for the
general Internet.
For RRC, the recommendations in Section 7.5 of
[I-D.ietf-tls-dtls-rrc] apply. Just like the handshake initial
timers, it is RECOMMENDED that DTLS 1.2 and 1.3 implementations offer
an option for their developers to explicitly set the RRC timer.
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,
mglt: I do nto see why SNI is mandated. I believe this is too strong. I would
prefer a SHOULD with the explanation to why this is recommended. I suspect this
is is to interact with services hosted in the cloud.
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.
...
13. Maximum Fragment Length Negotiation
The Maximum Fragment Length Negotiation (MFL) extension has been
superseded by the Record Size Limit (RSL) extension [RFC8449].
Implementations in compliance with this specification MUST implement
the RSL extension and SHOULD use it to indicate their RAM
limitations.
mglt: I think RAM limitation is only one example. What came immediately to my
mind is that the device MUST ensure large packets are discarded.
14. Crypto Agility
...
15. Key Length Recommendations
...
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: this sounds for other non-CoAP as a SHOULD NOT unless....
17. Certificate Profile
...
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-T] [LwM2M-C].
Hence, the use of IDevIDs is limited on purpose even though they have
a long lifetime, or do not expire at all.
mglt: I think the purpose needs to be specified. In general any certificate has
a purpose.
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.
mglt: The last sentence is unclear to me. I think the "certificate content"
should be replaced by IDevIDs.
This document uses the terminology and some of the rules for
populating certificate content defined in IEEE 802.1AR. However,
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: I think we need to explain why we do not refer simply to 802.1AR. It
seems we are defining a profile that look s like 802.1AR but still different.
The question becomes why should we add another standard as opposed to using
802.1AR.
17.1. All Certificates
mglt: we probably need to explain why we have "All Certificates". The profile
as I understand is limited to the certificate that represents the IoT device.
This means that if an IoT device contact a Web Server. The IoT device will have
the certificate in this document while the Web Server will have the CABF.
To avoid repetition, this section outlines requirements on X.509
certificates applicable to all PKI entities.
Tschofenig, et al. Expires 21 April 2026 [Page 10]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
17.1.1. Version
Certificates MUST be of type X.509 v3.
mglt: and v3 = 2 ;-). The text below is in my opinion not related to the
version section and could be moved to the intro of the certificate section 17.
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.
17.1.2. Serial Number
CAs MUST generate non-sequential serial numbers greater than or equal
to eight (8) octets from a cryptographically secure pseudo-random
number generator. [RFC5280] limits this field to a maximum of 20
octets. The serial number MUST be unique for each certificate issued
by a given CA (i.e., the issuer name and the serial number uniquely
identify a certificate).
This requirement is aligned with [RFC5280].
mglt: not CABF provides additional requirement on the randome generator.
17.1.3. Signature
The signature MUST be ecdsa-with-SHA256 or stronger [RFC5758].
Note: In contrast to IEEE 802.1AR this specification does not require
end entity certificates, subordinate CA certificates, and CA
certificates to use the same signature algorithm. Furthermore, this
specification does not utilize RSA for use with constrained IoT
devices and networks.
mglt: using different signatures requires the IoT device to support all these
signature scheme. It makes sense for certificates verified by IoT devices to
have a single signature.
17.1.4. Issuer
The issuer field MUST contain a non-empty distinguished name (DN) of
the entity that has signed and issued the certificate in accordance
with [RFC5280].
17.1.5. Validity
Vendors must determine the expected lifespan of their IoT devices.
This decision directly affects how long firmware and software updates
are provided for, as well as the level of maintenance that customers
can expect. It also affects the maximum validity period of
certificates.
In most IoT deployments, IDevIDs are provisioned with an unlimited
lifetime as per [IEEE-802.1AR]. For this purpose, a special value
for the notAfter date field, the GeneralizedTime value of
99991231235959Z, is utilized. This special value was introduced in
Section 4.1.2.5 of [RFC5280]. When this is done, then the CA
...
mglt: The problem is that a device that is unable to determien which UTC time
it is can hardly ensure the notAfter especially as leap seconds can be added or
removed. The CABF text is quite confusing to me, but it seems the reasonable
way to do is to ignore leap seconds and define days as 8640 oseconds. This
seems to me close to TAI than UTC - with non atomic clock, a UT1 or pre-50
conception of the second, while certificates expresses time in UTC. I think
what is more important is to say that systems do not have a precision of the
second.
17.1.6. Subject Public Key Info
The subjectPublicKeyInfo field indicates the algorithm and any
associated parameters for the ECC public key. This profile uses the
id-ecPublicKey algorithm identifier for ECDSA signature keys, as
defined and specified in [RFC5480]. This specification assumes that
devices supported one of the following algorithms:
* id-ecPublicKey with secp256r1,
* id-ecPublicKey with secp384r1, and
* id-ecPublicKey with secp521r1.
There is no requirement to use CA certificates and certificates of
subordinate CAs to use the same algorithm as the end entity
certificate. Certificates with longer lifetime may well use a
cryptographic stronger algorithm.
mglt: we should probably recommend it when the certificate needs to be
validated by an IoT.
Tschofenig, et al. Expires 21 April 2026 [Page 12]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
17.1.7. Certificate Revocation Checks
The Certificate Revocation Lists (CRLs) 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.
mglt: The sentence is confusing. It might be clearer to provide the explicit
recommended combination of extensions. AIK may contains caissuer as well which
is unrelated to CRL, so I do not clearly see why these extensions are not
recommened to be used together. The coexistence might also depends on the
lifetime of the certificates.
If set, they MUST NOT be
marked critical.
Instead of using CRLs or OCSP this document follows the guidance in
Section 4.4.3 of [RFC7925]: for certificate revocation, neither OCSP
nor CRL are used by constrained IoT devices.
mglt: It is unclear if that recommendation is one step further than the
previous one or if the previous one was NEITHER extensions SHOULD be set.
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, allow for the distribution and updating of
certificates on demand. An example of a standardized IoT device
management protocol is the Lightweight Machine-to-Machine (LwM2M)
[LwM2M-T] [LwM2M-C] protocol. Device management protocols enable a
deployment model where IoT devices 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.
mglt: this is not correct. TLS authenticates during the handshake, so new
certificates renewal does not affect the end point of the communications. If
the end points want to constantly validate the certificate, this is a policy
that is separate from TLS and in effect TLS does not permit this. This has to
be done via HTTP for example.
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: Continuous certificate validation goes beyond TLS, and is outside the
scope of this draft in my opinion. It might be interesting information but what
needs to be added is what is the advantage over re-establishing ab ECDHE TLS
session.
Hence, instead of performing certificate revocation checks on the IoT
device itself this it is RECOMMENDED to delegate this task to the IoT
device operator and to take the necessary action to allow IoT devices
to remain operational.
mglt: we need to specify what certificate revocation checks are considered here
- continuous certificate validity versus crl/ocsp. I think the point is more,
that OCSP/CRL extension can be omitted only when the operator of a control and
managed system can ensure certificates present are up to date.
dm: It is my beleive that a specific OID policy shoudl be provide for the
profile.
mglt: I just realized the section is generic to Root CA, Subordinate and End
ENtity certificates. Some comments might only be related to EE.
17.2. Root CA Certificate
This section outlines the requirements for root CA certificates. We should
recommend SAN in my opinion.
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.
Tschofenig, et al. Expires 21 April 2026 [Page 13]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
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."
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.
mglt: Why not saying RECOMMENDED.
17.2.3. Subject Key Identifier
Section 4.2.1.2 of [RFC5280] defines the SubjectKeyIdentifier as
follows: "The subject key identifier extension provides a means of
identifying certificates that contain a particular public key."
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.
The subjectKeyIdentifier is used by path construction algorithms to
identify which CA has signed a subordinate certificate.
mglt: CABF mandates it. I think we should follow CABF.
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.
mglt: CABF mandates KU. It is my belief we should follow these recommendations.
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."
This extendedKeyUsage extension MUST NOT be set in CA certificates.
Tschofenig, et al. Expires 21 April 2026 [Page 14]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
17.2.5. Basic Constraints
[RFC5280] states that "The Basic Constraints extension identifies
whether the subject of the certificate is a CA and the maximum depth
of valid certification paths that include this certificate. The cA
boolean indicates whether the certified public key may be used to
verify certificate signatures."
For the pathLenConstraint RFC 5280 makes further statements:
* "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.
17.3. Subordinate CA Certificate
This section outlines the requirements for subordinate CA
certificates.
17.3.1. Subject
The subject field MUST be set and MUST contain the commonName, the
organizationName, and the countryName attribute and MAY contain an
organizationalUnitName attribute.
17.3.2. Authority Key Identifier
The Authority Key Identifier extension MUST be set, MUST NOT be
marked critical, and MUST contain the subjectKeyIdentifier of the CA
that issued this certificate.
Tschofenig, et al. Expires 21 April 2026 [Page 15]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
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.
17.3.4. Key Usage
The Key Usage extension MUST be set, MUST be marked critical, the
keyCertSign or cRLSign purposes MUST be set, and the digitalSignature
purpose SHOULD be set.
Subordinate certification authorities SHOULD NOT have any
extendedKeyUsage. [RFC5280] reserves EKUs to be meaningful only in
end entity certificates.
17.3.5. Basic Constraints
The Basic Constraints extension MUST be set, MUST be marked critical,
the cA flag MUST be set to true and the pathLenConstraint SHOULD be
omitted.
17.3.6. CRL Distribution Point
The CRL Distribution Point extension SHOULD NOT be set. If it is
set, it MUST NOT be marked critical and MUST identify the CRL
relevant for this certificate.
17.3.7. Authority Information Access
The Authority Information Access extension SHOULD NOT be set. If it
is set, it MUST NOT be marked critical and MUST identify the location
of the certificate of the CA that issued this certificate and the
location it provides an online certificate status service (OCSP).
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.
Tschofenig, et al. Expires 21 April 2026 [Page 16]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
[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], [IEEE-802.1AR]) 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.
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.
mgt: my understanding is thet X520SerialNumber is defined in 5280 and that the
use of serial in the subject. I think that it would be clearer if it were
indicated the attribute is in teh subject. Now, if teh serial numbe ris an
identifier, it shoudl eb placed in teh SAN as an URI in my opinion.
[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
(Section 5 of [RFC4108]). This specification does not follow this
recommendation.
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
Tschofenig, et al. Expires 21 April 2026 [Page 17]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
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: In the beginning SNI was mandated in TLS.
17.4.2. Authority Key Identifier
The Authority Key Identifier extension MUST be set, MUST NOT be
marked critical, and MUST contain the subjectKeyIdentifier of the CA
that issued this certificate.
17.4.3. Subject Key Identifier
The Subject Key Identifier MUST NOT be included in end entity
certificates, as it can be calculated from the public key, so it just
takes up space. End entity certificates are not used in path
construction, so there is no ambiguity regarding which certificate
chain to use, as there can be with subordinate CAs.
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.
As specified in [IEEE-802.1AR], the extendedKeyUsage SHOULD NOT be
present in IDevID certificates, as it reduces the utility of the
IDevID. For locally assigned LDevID certificates to be usable with
TLS, the extendedKeyUsage MUST contain at least one of the following:
id-kp-serverAuth or id-kp-clientAuth.
18. Update of Trust Anchors
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
Tschofenig, et al. Expires 21 April 2026 [Page 18]
Internet-Draft TLS/DTLS 1.3 IoT Profiles October 2025
anchors and not end entity certificates or certificates of
subordinate CAs.
As an alternative, certificate management protocols like CMP and EST
have also offered ways to update trust anchors. See, for example,
Section 2.1 of [RFC7030] for an approach to obtaining CA certificates
via EST.
19. Certificate Overhead
In a public key-based key exchange, certificates and public keys are
a major contributor to the size of the overall handshake. For
example, in a regular TLS 1.3 handshake with minimal ECC certificates
and no subordinate CA utilizing the secp256r1 curve with mutual
authentication, around 40% of the entire handshake payload is
consumed by the two exchanged certificates.
Hence, it is not surprising that there is a strong desire to reduce
the size of certificates and certificate chains. This has led to
various standardization efforts. Below is a brief summary of what
options an implementer has to reduce the bandwidth requirements of a
public key-based key exchange. Note that many of the standardized
extensions are not readily available in TLS/DTLS stacks since
optimizations typically get implemented last.
* Use elliptic curve cryptography (ECC) instead of RSA-based
certificate due to the smaller certificate size. This document
recommends the use of elliptic curve cryptography only.
* Avoid deep and complex CA hierarchies to reduce the number of
subordinate CA certificates that need to be transmitted and
processed. See [I-D.irtf-t2trg-taxonomy-manufacturer-anchors] for
a discussion about CA hierarchies. Most security requirements can
be satisfied with a PKI depth of 3 (root CA, one subordinate CA,
and end entity certificates).
mglt: with AIA do we really need to have the full chain as the receiver with
sufficient resources may get the chain from the CA. no ?
On Fri, Oct 31, 2025 at 11:40 AM Renzo Navas <[email protected]
<mailto:[email protected]> > wrote:
Hi All,
I am the shepherd of this document.
Just a friendly reminder for @Daniel:
can you take a look at the modifications for the authors?
Do they mostly address your comments?
If that is the case, (now I am speaking for the WG Chairs), we will be
able to move forward in the procedure, right?
See you in Montreal maybe (I will be attending physically)
Regards,
Renzo
On Sat, Oct 18, 2025 at 12:24 PM Tschofenig, Hannes
<[email protected] <mailto:[email protected]> > wrote:
>
> Hi Daniel,
>
>
>
> We have just submitted a new version of the “TLS/DTLS 1.3 Profiles for the
> Internet of Things” draft.
>
> This specification update was in the result of your detailed review, Daniel.
>
>
>
> In response to the review MCR has identified more than 30 issues, which he
> captured in the Github repo at
> https://github.com/thomas-fossati/draft-tls13-iot/issues
>
>
>
> Responses are captured in the respective issues. Daniel, please have a look
> and see whether you are satisfied with the response and the updated text in
> the draft. (I copied text for most of issues into the Github issue page
> directly for easier processing).
>
>
>
> Your review has certainly improved the quality of the write-up. Thanks!
>
>
>
> Ciao
>
> Hannes
>
> (On behalf of the authors)
>
> _______________________________________________
> Uta mailing list -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]>
--
Daniel Migault
Ericsson
_______________________________________________
Uta mailing list -- [email protected]
To unsubscribe send an email to [email protected]
