Re: [Dtls-iot] [OPS-DIR] Ops-dir review of draft-ietf-dice-profile-14

[Hannes Tschofenig <[e-mail]>]

Hi Tina,

thanks for your detailed review.

On 09/05/2015 02:44 AM, Tina TSOU wrote:
> 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.


I tried to put the recommendations at the end of the respective sections
and the background of how a particular features is relevant at the front.

While you are very familiar with the described documents the main target
audience, i.e., developers are so familiar with all the specifications
and their relevance for an IoT environment. When you look at the
security of IoT devices provided today then you will for sure agree with
me that there are not only security experts around. Hence, a bit more
background material will help these folks a lot to understand why we are
introducing certain features.

>> * 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.
> 

The problem I encountered in referencing a software update mechanism, as
Stephen also pointed out in his reviews, is that I cannot easily point
to one single mechanism. I pointed to the mechanism specified in the OMA
LWM2M specification as one possible mechanism but it is also incomplete.
I believe that this is an area of work that requires a separate set of
specifications...


> 
> * 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...
> 

Here is the new proposed wording:
"
The named Diffie-Hellman groups [I-D.ietf-tls-negotiated-dl-dhe] are not
applicable to this profile since it relies on the ECC-based counterparts.
"

> 
> * 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?

Fixed.

> 
> 
> * 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.
> 

Added a reference to the Wikipedia page.

> 
> * 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?

I tried to provide examples of IP address changes.
There is nothing special about renumbering as such.

I simplified the text:

"
The DTLS handshake may need to be re-started (ideally using session
resumption, if possible) in case of an IP address change.
"

> 
> 
> **** Editorial/Nits ****
> * Abstract:
> 
>> via sensor or
>> controls actuators for use in home automation,
> 
> s/sensor/sensors/
> 
> 
Fixed.

> * 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.

Fixed.

> 
> 
> * 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.
> 
Fixed.

> 
> * 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".

Fixed.

> 
> 
> * Section 4.2, page 15:
>> several other eco-system factor
> 
> s/factor/factors/
> 

Fixed.

> 
> * Section 4.2, page 16:
>> to establish an shared
>> key
> 
> s/an/a/

Fixed.

> 
> 
> * Section 4.2, page 17:
>> and various position papers submitted to that topic
> 
> s/to/on/?
> 
Fixed.

> 
> * 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"?
> 
Fixed

> 
> * Section 4.2, page 17:
>> authenticate both endpoint
> 
> s/endpoint/endpoints/

Fixed.

> 
> 
> * Section 4.2, page 18:
>> CoAP 2.04 Changed
> 
> s/2.04/2.05 <x-apple-data-detectors://12>/?

I am not sure what this means.


> 
> 
> * Section 6.1, page 20:
>> has to be know
> 
> s/know/known/

fixed.

> 
> 
> * 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/
Fixed.

> 
> 
> * 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/?
> 
> 
Fixed.


> * Section 6.3, page 24:
> 
>> namely the server_certificate_type*’
> 
> Not sure if e.g. the asterisk was included in error.
> 

A mistake. Fixed.

> 
> * Page 27:
>> 3. Certificates MUST NOT contains multiple names (e.g., more than
>> one dNSName field).
> 
> s/contains/contain/
> 
> 

Fixed.


> * Page 33:
>> For cases where the server constrained
> 
> Missing "is".
> 

Fixed.

> 
> Have a good weekend.
> 
> 
> Thank you,
> Tina
> 
Thanks!

Ciao
Hannes

> 
> _______________________________________________
> OPS-DIR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ops-dir
>