Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: <email@example.com>, <firstname.lastname@example.org>, The IESG <email@example.com>, <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, <email@example.com> Subject: Protocol Action: 'TLS/DTLS Profiles for the Internet of Things' to Proposed Standard (draft-ietf-dice-profile-17.txt) The IESG has approved the following document: - 'TLS/DTLS Profiles for the Internet of Things' (draft-ietf-dice-profile-17.txt) as Proposed Standard This document is the product of the DTLS In Constrained Environments Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dice-profile/
Technical Summary A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensor 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 TLS (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 Internet of Things products that can easily be solved by using these well-researched and widely deployed Internet security protocols. Working Group Summary There was no controversy about this document. Document Quality The document has been reviewed by various DICE working group participants. Due to the nature of the document additional review from the security community is essential. Various implementations of embedded TLS stacks exist on the market (open source as well as closed source implementations) that implement a subset of the functionality defined in the specification. A 2nd IETF LC for a downref to RFC7251 may happen if someone complains. I'm arguing it's not needed as RFC7252 already has 7251 as a normative reference and CCM is in any case well accepted by the community. If some AD wants to do the process Personnel Zach Shelby is the document shepherd, Stephen Farrell is the sometimes-responsible AD.