Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
draft-ietf-dice-profile-17

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: <zach.shelby@arm.com>, <draft-ietf-dice-profile@ietf.org>, The IESG <iesg@ietf.org>, <stephen.farrell@cs.tcd.ie>, dtls-iot@ietf.org, dice-chairs@ietf.org, <rfc-editor@rfc-editor.org>
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/

Ballot Text

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.

RFC Editor Note