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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gabriel,

thanks for your review comments.

I am OK with the proposed text changes.

A minor remark regarding the stacks used in IoT devices: In the stacks I
have seen the developer has the possibility to include or exclude
certain features using preprocessor directives. Even if you have the
ability to re-use a TLS/DTLS stack on devices that have nothing to do
with IoT and have no code size restriction you will typically have to
remove features for an IoT device to keep the code size at a reasonable
level.

I am, of course, aware of devices that have very few limitations in
terms of processing speed, RAM, and flash size. The boundaries between
IoT devices and non-IoT devices is certainly fuzzy.

Ciao
Hannes

On 09/04/2015 01:21 AM, g_e_montenegro@xxxxxxxxx wrote:
> 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 https://tools.ietf.org/html/draft-ietf-dice-profile-14#section-15: 
> 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
> https://tools.ietf.org/html/draft-ietf-dice-profile-14#section-10 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.
> 
> thanks,
> 
> Gabriel
> 
> 
> 
> On Friday, August 21, 2015 6:53 AM, The IESG <iesg-secretary@xxxxxxxx>
> 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
>     ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> mailing lists by 2015-09-04.
>     Exceptionally, comments may be
>     sent to iesg@xxxxxxxx <mailto:iesg@xxxxxxxx> instead. In either
>     case, please retain the
>     beginning of the Subject line to allow automated sorting.
> 
>     Abstract
> 
> 
>       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
>     https://datatracker.ietf.org/doc/draft-ietf-dice-profile/
> 
>     IESG discussion can be tracked via
>     https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ballot/
> 
> 
>     No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/dtls-iot
> 

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]