Last Call Review of draft-ietf-dice-profile-14
review-ietf-dice-profile-14-opsdir-lc-tsou-2015-09-11-00

Dear all,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed
 by the IESG.  These comments were written primarily for the benefit of the
 operational area directors.

Document editors and WG chairs should treat these comments just like any other
last call comments.

This I-D is almost ready for publication. Hopefully you can address my

comments below:

**** Technical ****

Meta:

In many cases, the recommendations being made are kind of intermixed

with the "background" information. If the text is not reorganized such

that the recommendations are more "separated" from the background info,

it would be great if, e.g. in each section, you provide a summary

(possibly in the form of a table) of all the recommendations being made.

* Section 6.1, page 21:

IoT device are assumed to have a software update

mechanism built-in and it will allow updates of low-level device

information, including credentials and configuration parameters.

This document does, however, not mandate a specific software /

firmware update protocol.

If you talk about software update mechanisms, you should probably make

some comments about the software update mechanism. e.g., it should

authenticate the software it downloads.

* Section 6.3, pages 24/25

Due to the use of Ephemeral Elliptic Curve

Diffie-Hellman (ECDHE) the recently introduced named Diffie-Hellman

groups [I-D.ietf-tls-negotiated-dl-dhe] are not applicable to this

profile.

I find this para graph hard to parse...

* Section 6.4.4:

All certificate elements listed in Table 1 are mandatory-to-implement

for client and servers claiming support for certificate-based

authentication. No other certificate elements are used by this

specification

Should there be any RFC2119 language here?

* Page 33:

Section 3.3 of [RFC7525] recommends to disable TLS/DTLS-level

compression due to attacks, such as CRIME.

Please provide a reference for CRIME -- RFC7525 doesn't seem to have

one, either.

* Page 35:

Since the upload happens on an irregular and unpredictable basis

and due to renumbering and Network Address Translation (NAT) the

DTLS handshake may need to be re-started (ideally using session

resumption, if possible).

Could you please elaborate why you mention "renumbering" as one of such

reasons?

**** Editorial/Nits ****

* Abstract:

via sensor or

controls actuators for use in home automation,

s/sensor/sensors/

* Section 1, pag 3:

UDP is mainly used to carry CoAP messages but other

transports can be utilized, such as SMS or even TCP.

Please add appropriate references.

* Section 1, pag 3:

While the main goal for this document is to protect CoAP messages

using DTLS 1.2 [RFC6347]

Add a comma right after the reference.

* Section 4.1.1.2, page 11:

this might be too limiting and additional functionality is needed, as

shown in Figure 4 and Figure 4,

* Section 4.2, page 13:

In this section, we assume a scenario where constrained devices run

TLS/ DTLS servers

Remove the extra space in "TLS/ DTLS".

* Section 4.2, page 15:

several other eco-system factor

s/factor/factors/

* Section 4.2, page 16:

to establish an shared

key

s/an/a/

* Section 4.2, page 17:

and various position papers submitted to that topic

s/to/on/?

* Section 4.2, page 17:

For a more fine-grained and

dynamic access control

Maybe rephrase as "For a finer-grained and more dynamic access control"?

* Section 4.2, page 17:

authenticate both endpoint

s/endpoint/endpoints/

* Section 4.2, page 18:

CoAP 2.04 Changed

s/

2.04/2.05

/?

* Section 6.1, page 20:

has to be know

s/know/known/

* Section 6.1, page 21:

Whatever process for generating

these initial device credential

* Section 6.1, page 21:

IoT device are assumed to have a software update

mechanism built-in and it will allow updates of low-level device

information, including credentials and configuration parameters.

This document does, however, not mandate a specific software /

firmware update protocol.

s/device/devices/

* Section 6.2, page 21:

The use of pre-shared secrets is one of the most basic techniques for

TLS/DTLS since it is both computational efficient and bandwidth

conserving

s/computational/computationally/?

* Section 6.3, page 24:

namely the server_certificate_type*’

Not sure if e.g. the asterisk was included in error.

* Page 27:

3. Certificates MUST NOT contains multiple names (e.g., more than

one dNSName field).

s/contains/contain/

* Page 33:

For cases where the server constrained

Missing "is".

Have a good weekend.

Thank you,

Tina