[Dtls-iot] Barry Leiba's No Objection on draft-ietf-dice-profile-16: (with COMMENT)

"Barry Leiba" <barryleiba@computer.org> Thu, 01 October 2015 04:50 UTC

Return-Path: <barryleiba@computer.org>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 61A991AD363; Wed, 30 Sep 2015 21:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cQbHw0iKQPsh; Wed, 30 Sep 2015 21:50:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EA11AD35A; Wed, 30 Sep 2015 21:50:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Barry Leiba" <barryleiba@computer.org>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151001045025.31747.39754.idtracker@ietfa.amsl.com>
Date: Wed, 30 Sep 2015 21:50:25 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtls-iot/sJ-4rHzbh4I_wOSnURUtOnIQryc>
Cc: zach.shelby@arm.com, dtls-iot@ietf.org, dice-chairs@ietf.org, draft-ietf-dice-profile.shepherd@ietf.org, draft-ietf-dice-profile@ietf.org, draft-ietf-dice-profile.ad@ietf.org
Subject: [Dtls-iot] Barry Leiba's No Objection on draft-ietf-dice-profile-16: (with COMMENT)
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 04:50:27 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-dice-profile-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Just some editorial comments here that the RFC Editor isn't likely to

-- Section 1 --

   UDP is mainly used to carry CoAP messages but other
   transports can be utilized

This is worded oddly, as it looks as if it's saying that the main use of
UDP is to carry CoAP messages.  Please consider this instead:

   CoAP messages are mainly carried over UDP, but other
   transports can be utilized

-- Section 3.1 --

   However, since DTLS operates on top of an unreliable datagram
   transport, it must explicitly cope with the reliable and ordered
   delivery assumptions made by TLS.

It must explicitly cope with the *absence of* reliable and ordered
delivery.  Please consider re-wording this.

-- Section 4.4.4 --

   There are various algorithms used to sign digital certificates, such
   as RSA, the Digital Signature Algorithm (DSA), and the Elliptic Curve
   Digital Signature Algorithm (ECDSA).  As Table 1 indicates
   certificate are signed using ECDSA.

This initially confused me.  First, the "such as" modifier appears to
apply to "digital certificates", when it's actually meant to apply to
"algorithms".  Then the second sentence seemed to contradict the first,
until I realized that it's incomplete.  Please consider this:

   There are various algorithms used to sign digital certificates; those
   algorithms include RSA, the Digital Signature Algorithm (DSA), and
   the Elliptic Curve Digital Signature Algorithm (ECDSA).  As Table 1
   shows, in this profile certificates are signed using ECDSA.

-- Section 4.4.6 --

   With certificate-based authentication a DTLS server conveys
   its end entity certificate to the client during the DTLS exchange

Something's wrong with this sentence (the part that begins with
"during"), but I can't figure out what.

-- Section 6 --

   All error messages marked as RESERVED are only supported for
   backwards compatibility with SSL MUST NOT be used with this profile.

You're missing "and" before "MUST NOT".

-- Section 13 --

   Implementations conformant to this specification MUST use AEAD
   ciphers.  Hence, RFC 7366 and the Truncated MAC extension of RFC 6066
   are not applicable to this specification and are NOT RECOMMENDED.

To me, "not applicable" says more than "NOT RECOMMENDED".  Why is this
not "MUST NOT be used"?

-- Section 17 --

   To prevent the re-negotiation attack [RFC5746] this specification
   RECOMMENDS to disable the TLS renegotiation feature.  Clients MUST
   respond to server-initiated re-negotiation attempts with an alert
   message (no_renegotiation) and clients MUST NOT initiate them.

Doesn't the second sentence actually say that this specification REQUIRES
(not "RECOMMENDS") disabling of the TLS renegotiation feature?

-- Section 18 --

   If at some time in the future this profile reaches the quality of SSL
   3.0 a software update is needed since constrained devices are
   unlikely to run multiple TLS/DTLS versions due to memory size

I don't understand this.  What does "reaches the quality of SSL 3.0"