TLS/DTLS 1.3 Profiles for the Internet of ThingsArm LimitedHannes.Tschofenig@gmx.netArm LimitedThomas.Fossati@arm.com
Security
UTAInternet-DraftThis document is a companion to RFC 7925 and defines TLS/DTLS 1.3 profiles for
Internet of Things devices. It also updates RFC 7925 with regards to the X.509
certificate profile.Discussion VenuesSource for this draft and an issue tracker can be found at
https://github.com/thomas-fossati/draft-tls13-iot.IntroductionThis 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 TerminologyThe 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 TypesIn 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 HandlingTLS 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 ResumptionTLS 1.3 has built-in support for session resumption by utilizing PSK-based
credentials established in an earlier exchange.CompressionTLS 1.3 does not have support for compression.Perfect Forward SecrecyTLS 1.3 allows the use of PFS with all ciphersuites since the support for it is
negotiated independently.Keep-AliveThe discussion in Section 10 of is applicable.TimeoutsThe 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 GenerationThe 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 NegotiationThe 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 AgilityThe recommendations in Section 19 of are applicable.Key Length RecommendationsThe recommendations in Section 20 of are applicable.0-RTT DataWhen 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 .Certificate ProfileThis 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?CompressionThe 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 ConsiderationsThis entire document is about security.IANA ConsiderationsIANA is asked to add the Option defined in to the CoAP
Option Numbers registry.IANA is asked to add the Response Code defined in to the
CoAP Response Code registry.ReferencesNormative ReferencesThe Datagram Transport Layer Security (DTLS) Protocol Version 1.3This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of ThingsA common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Record Size Limit Extension for TLSAn extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.This replaces the maximum fragment length extension defined in RFC 6066.Using Early Data in HTTPUsing TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.Informative ReferencesTLS Encrypted Client HelloThis document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key.CBOR Profile of X.509 CertificatesThis document specifies a CBOR encoding and profiling of X.509 public key certificate suitable for Internet of Things (IoT) deployments. The full X.509 public key certificate format and commonly used ASN.1 DER encoding is overly verbose for constrained IoT environments. Profiling together with CBOR encoding reduces the certificate size significantly with associated known performance benefits. The CBOR certificates are compatible with the existing X.509 standard, enabling the use of profiled and compressed X.509 certificates without modifications in the existing X.509 standard.TLS Certificate CompressionIn TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.CBOR Object Signing and Encryption (COSE): Headers for Carrying CBOR Compressed CertificatesCertificate chains often take up the majority of the bytes transmitted in COSE message that carry certificates. Large messages can cause problems, particularly in constrained IoT environments. RFC 7925 defines a certificate profile for constrained IoT. General purpose compression algorithms can in many cases not compress RFC 7925 profiled certificates at all. By using the fact that the certificates are profiled, the CBOR certificate compression algorithms can in many cases compress RFC 7925 profiled certificates with over 50%. This document specifies the CBOR certificate compression algorithm for use with COSE.