Re: [Dtls-iot] Last Call: <draft-ietf-dice-profile-14.txt> (TLS/DTLS Profiles for the Internet of Things) to Proposed Standard

<> Thu, 03 September 2015 23:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BF4411B3AEC for <>; Thu, 3 Sep 2015 16:21:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.459
X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dF8n-hMS4m-q for <>; Thu, 3 Sep 2015 16:21:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6E991B313E for <>; Thu, 3 Sep 2015 16:21:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1441322502; bh=d2MjiaZTuxg8OjXvZkIkcUEWxLy0slQ1XNWJ+e+NdJ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=e8iS/PfWvLbRr8XwGqix74+bcYhWa9PNDV+y+VqBoeBDkYrFlJKmp9ZeB8En6mAEnlVzwO0vbwtRFT3zQVOHpCi+6Vh3VJSpDGugsd6gI9fiCU9CAxJ8f9jLfkPm0rvWxC89TINYEYKBbc7WidZkYnvTPj4KCnWdNjhRStX2ktdZCesOzAzw0+czjQaMuGq4uPrh5TaxhbSJFVGa6ZLqYW/KdQn96e/bK8leRmx0DuZ08tYE7hKKzU3geYCMVCT8Pzrf2mQg6tl4OusxS3guEvaiGE/6BuZ/b41c6UeqXrSFIBJGTJAiGA/aGurYHwxlzLV8I3gRe8suKF+tDWr3/g==
Received: from [] by with NNFMP; 03 Sep 2015 23:21:42 -0000
Received: from [] by with NNFMP; 03 Sep 2015 23:21:42 -0000
Received: from [] by with NNFMP; 03 Sep 2015 23:21:42 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: IeWYB.cVM1lupOGrhllfFGYmosJmxLDhPcK78Rg1Qc._fyCA_CFjRqHakyoqDvt qC4OCSoQe62A.tKMnNhc_w4jrDhCpTVInH1yTUOo3XTpnGEGun6YxePLbsTz2Zc0RC2UX7K_7h83 OX0_VFqk8n4d8gA1GbgoOZfdz0MpO4Cx0W06dQ5uTOBpQDu1bLpG6e8.OKyLjEBfQ97PXe_RHrAi O2FeG_E8xxSjAPYQ8WUpfI0jNgC5xNdpJN8p0psxIQXmn8F4xsIhjiOSG4S7AanZsGwJI67dONfj axlBkfGf6qUcfSIH7jr9Nt6Kaa4hCnVPEB0xNDKFzrrYhUFYJxPXFnHrZrAufgpg7ZebUkfA3y1Y c.UgKyQhj47lB26bGBPKzGYKCwDiOEjTcMDCwdh_vY76SFv9oW6LvDoqB9ju1F8flSrWb0j4yJTd Xlq_fmYtY3zh4FBQs52fgY0oeLO7lR.Zyjzu8i1Wa87I-
Received: by; Thu, 03 Sep 2015 23:21:41 +0000
Date: Thu, 3 Sep 2015 23:21:38 +0000 (UTC)
From: <>
To: "" <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1263190_419588596.1441322498330"
Archived-At: <>
Cc: "" <>
Subject: Re: [Dtls-iot] Last Call: <draft-ietf-dice-profile-14.txt> (TLS/DTLS Profiles for the Internet of Things) to Proposed Standard
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Sep 2015 23:21:45 -0000

Overall, looks good, thanks for this work. I do have some comments.
Not sure if these are "substantive comments" as requested, but after some discussion with some collegues we'd like to point out issues with some of the normative language.
In particular, we suggest modifying the language here:
 Hence, RFC 7366 and RFC 6066 are not applicable to this specification and MUST NOT be implemented.
Whereas CCM and AEAD ciphers in general render RFC7366 moot, a MUST NOT on implementation is too strong (i.e., from the intro, “This document does not alter TLS/DTLS specifications”) and potentially damaging: the same stack could be used for scenarios outside of IoT, where RFC7366 could still provide some benefit. As for RFC6066, a blanket statement saying it “MUST NOT implement” is not only wrong, it is also contradictory with other statements within this draft which recommend other parts of RFC6066. Instead, the language should limit itself to the specific extension of RFC6066. 
Also, with other extensions the doc does not prohibit *implementation*, but recommends against it or against its use (by using "NOT RECOMMENDED"). So I’d change the above text to something like:
In OLD:         Hence, RFC 7366 and RFC 6066 are not applicable to this        specification and MUST NOT be implemented.NEW:         Hence, RFC 7366 and the Truncated MAC extension of RFC 6066 are not applicable to this         specification and are NOT RECOMMENDED.
Similarly, in my suggestion would be: OLD:          This TLS/DTLS profile MUST NOT implement TLS/DTLS layer compression.NEW:          TLS/DTLS layer compression is NOT RECOMMENDED by this TLS/DTLS profile.

     On Friday, August 21, 2015 6:53 AM, The IESG <> wrote:

The IESG has received a request from the DTLS In Constrained Environments
WG (dice) to consider the following document:
- 'TLS/DTLS Profiles for the Internet of Things'
  <draft-ietf-dice-profile-14.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the mailing lists by 2015-09-04. Exceptionally, comments may be
sent to instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.


  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.

The file can be obtained via

IESG discussion can be tracked via

No IPR declarations have been submitted directly on this I-D.