TLS/DTLS 1.3 Profiles for the Internet of Things

Introduction This document defines a profile of DTLS 1.3 and TLS 1.3 that offers communication security services for IoT applications and is reasonably implementable on many constrained devices. Profile thereby means that available configuration options and protocol extensions are utilized to best support the IoT environment. For IoT profiles using TLS/DTLS 1.2 please consult . This document re-uses the communication pattern defined in and makes IoT-domain specific recommendations for version 1.3 (where necessary). TLS 1.3 has been re-designed and several previously defined extensions are not applicable to the new version of TLS/DTLS anymore. This clean-up also simplifies this document. Furthermore, many outdated ciphersuites have been omitted from the TLS/DTLS 1.3 specification.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Credential Types In accordance with the recommendations in , a compliant implementation MUST implement TLS_AES_128_CCM_8_SHA256. It SHOULD implement TLS_CHACHA20_POLY1305_SHA256. 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. A plain PSK-based TLS/DTLS client or server MUST implement the following extensions:

supported_versions
cookie
server_name
pre_shared_key
psk_key_exchange_modes

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 MUST be followed.

Error Handling TLS 1.3 simplified the Alert protocol but the underlying challenge in an embedded context remains unchanged, namely what should an IoT device do when it encounters an error situation. The classical approach used in a desktop environment where the user is prompted is often not applicable with unattended devices. Hence, it is more important for a developer to find out from which error cases a device can recover from.

Session Resumption TLS 1.3 has built-in support for session resumption by utilizing PSK-based credentials established in an earlier exchange.

Compression TLS 1.3 does not have support for compression.

Perfect Forward Secrecy TLS 1.3 allows the use of PFS with all ciphersuites since the support for it is negotiated independently.

Keep-Alive The discussion in Section 10 of is applicable.

Timeouts The recommendation in Section 11 of is applicable. In particular this document RECOMMENDED to use an initial timer value of 9 seconds with exponential back off up to no less then 60 seconds. Question: DTLS 1.3 now offers per-record retransmission and therefore introduces much less congestion risk associated with spurious retransmissions. Hence, should we relax the 9s initial timeout?

Random Number Generation The discussion in Section 12 of is applicable with one exception: the ClientHello and the ServerHello messages in TLS 1.3 do not contain gmt_unix_time component anymore.

Server Name Indication (SNI) This specification mandates the implementation of the SNI extension. Where privacy requirements require it, the encrypted SNI extension prevents an on-path attacker to determine the domain name the client is trying to connect to. Note, however, that the extension is still at an experimental state.

Maximum Fragment Length Negotiation The Maximum Fragment Length Negotiation (MFL) extension has been superseded by the Record Size Limit (RSL) extension . Implementations in compliance with this specification MUST implement the RSL extension and SHOULD use it to indicate their RAM limitations.

Crypto Agility The recommendations in Section 19 of are applicable.

Key Length Recommendations The recommendations in Section 20 of are applicable.

0-RTT Data When clients and servers share a PSK, TLS/DTLS 1.3 allows clients to send data on the first flight ("early data"). This features reduces communication setup latency but requires application layer protocols to define its use with the 0-RTT data functionality. For HTTP this functionality is described in . This document specifies the application profile for CoAP, which follows the design of . For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server). In general, if processing a request does not have state-changing side effects, the consequences of replay are not significant. The server can choose whether it will process early data before the TLS handshake completes. It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests. This specification specifies the Early-Data option, which indicates that the request has been conveyed in early data and that a client understands the 4.25 (Too Early) status code. The semantic follows .

Early-Data Option

Certificate Profile This section is intended for discussing updates to the certificate profile defined in . Initial set of things to consider:

pathLenConstraint

Question: should also we move the ASN.1 schema from Appendix B of here and let it have it by reference?

Compression The compression methods defined in do not seem to deal effectively with profiled certificates: zlib compresses the example cert by 9%, but other certificates and compression algorithms do in many cases increase the overall size. On the other hand, provides a more efficient scheme, yielding to compression rates higher than 50% (see Section 3 of ). Question: should we RECOMMEND CBOR compression? How is that negotiated?

Security Considerations This entire document is about security.

IANA Considerations IANA is asked to add the Option defined in to the CoAP Option Numbers registry.

Early-Data Option IANA is asked to add the Response Code defined in to the CoAP Response Code registry.

Too Early Response Code